ABAP_to_the_Future

Writing and Implementing Unit Tests 3.3
of procedural programs work by having al l the data in global variables. Such a
program can still benefit from unit testing; it just requires more effort (possibly a
lot more effort) in setting up the test to make sure the global variables are in the
correct state before the test is run.
Step Four: Evaluating the Test Result
Once you have some results back you will want to see if they are correct or not.
Next you will learn about the standard wa y of evaluating such results and then
how you can enhance the standard fram ework when the standard mechanism
doesn’t do everything you want. Finall y, you’ll see how to achieve 100% test
coverage.
Evaluating Test Results in the Normal Way
When you ran the test method that called the production code, either you got a
result back—table MT_BOM_DATA in the example—or some sort of publicly accessible
member variable of the class unde r test was updated—a status variable, perhaps.
Next, run one or more queries to see if the new state of the application is
what you expect it to be in the scenario you’re testing. This is done by looking at
one or more variable values and performing an evaluation (called an assertion) to
compare the actual value with the expected value. If the two values do not match,
then the test fails, and you specify the error message to be shown to the person
running the test (Listing 3.18).
"THEN
METHOD then_resulting_bom_is_correct.
* Local Variables
DATA: ls_bom_line LIKE LINE OF mt_bom_data.
ls_bom_line = bom_line_item( 1 ).
cl_abap_unit_assert=>assert_equals(
act = ls_bom_line-quantity
exp = 1
msg = 'Monster has wrong number of Heads'
quit = if_aunit_constants=>no ).
ls_bom_line = bom_line_item( 2 ).
cl_abap_unit_assert=>assert_equals(
act = ls_bom_line-quantity
exp = 2
msg = 'Monster has wrong number of Arms'
quit = if_aunit_constants=>no ).
157