A Spotlight on ABAP Unit Part 1

What ABAP Unit is All About

So you are an ABAP developer and want to write more tests, if it was not too difficult and took too long. You would like to achieve higher quality of your programs, and are unsure of how to accomplish this. After all, you are looking for a way to improve your code without investing much additional effort.

The solution for these problems is ABAP Unit, which is available with ABAP 6.40. This tool brings the well-known benefits of unit testing into the ABAP world. With ABAP Unit, testing for developers has become comfortable and far less time consuming than testing is supposed to be.

This tool is highly integrated both in the programming language and the development environment you are familiar with as an ABAP developer. Above all, it supports individual and mass testing equally well. So ABAP Unit reduces the testing effort during implementation in such a way that once you have understood the way it works you will enjoy

testing.

Surely, you are primarily interested in going directly into the matter without much ado. So before giving you any further explanations, let us start by giving you an impression of what working with ABAP unit is like.

This is part 1 of a weblog series on ABAP Unit. If you are interested, you find the other weblogs of the series here: A Spotlight on ABAP Unit Part 2, A Spotlight on ABAP Unit Part 3, A Spotlight on ABAP Unit Part 4, A Spotlight on ABAP Unit Part 5.

Getting Started – a Simplistic Example Program

With this tool you test small portions of code and write the test straight into the ABAP program you want to test. Let us start with a very simple program, for those who have always felt uncomfortable with percentages:

REPORT  percentages.
PARAMETERS: price TYPE p.
PERFORM minus_ten_percent CHANGING price.
WRITE price.
FORM minus_ten_percent CHANGING fprice TYPE p. 
     price = fprice * '0.9'.
ENDFORM.                    "minus_ten_percent

Our first ABAP Unit Test

Now we write a test which checks whether or not, for a given value, our little form does its job correctly:

CLASS test DEFINITION FOR TESTING. "#AU Risk_Level Harmless "#AU Duration   Short  
  PRIVATE SECTION.        
    METHODS test_minus_ten_percent FOR TESTING.
ENDCLASS.                   
CLASS test IMPLEMENTATION.    
  METHOD test_minus_ten_percent.        
    DATA: testprice type p value 200.        
    PERFORM minus_ten_percent CHANGING testprice.        
    cl_aunit_assert=>assert_equals( act = testprice exp = 180        
    msg = 'ninety percent not calculated correctly').    
  ENDMETHOD.                    
ENDCLASS.

The tests are implemented in plain ABAP Objects as methods of local test classes. The test classes are part of the program under test (PUT). This can be an executable program, a module pool, a function group, or class pool. The PUT can contain many test classes, and a test class can contain many test methods. All unit tests belonging to one PUT are organized in a test task.

In our fairly basic example there is only one test class with one test method. Both have FOR TESTING added to the declaration. Never forget this specification. The test method should be declared in the private section, because normally it is only called automatically by the test driver of the framework, when the test is executed, but not explicitly by any other part of your code.

In our example the test method test_minus_ten_percent first calls the form minus_ten_percent and sets the change parameter to 200. We compare the result of this calculation with the value we expect (180), by passing them as the parameters act and exp respectively to the method assert_equals of the service class cl_aunit_assert.

It is this method supported by the framework which offers a great service. If there is an error, for example: if the value expected and the actual value differs, the error is shown in the ABAP Unit result view, after the test is executed. By pushing just one button, or rather selecting a menu entry (in our case it is the menu path: Program->Test->Unit Test in the ABAP Editor), all the tests belonging to one task are run, and the errors will be presented to you in a clear and concise display. In case of our example, in the result display you are easily lead to the form:

FORM minus_ten_percent CHANGING fprice TYPE p.
price = fprice * '0.9'.

Obviously, we have mistaken the global data field price for the change parameter fprice. We change the line to: fprice = fprice * ‘0.9’, and run the test again. This time, we get the information that the test was successfully processed, which means: There was no error.

You see, with ABAP Unit the original error we had in our program was easily detected and tracked down. I will treat the details of the result display in another weblog when your knowledge of the ABAP Unit has increased after reading some of my subsequent weblogs. For the time being, I would like to address an objection that seems pretty natural, looking at the simplistic test we have written.

The Strong Use Cases For ABAP Unit: an Outlook

You have now received a first impression of how easy it is to work with ABAP Unit, and you are perhaps convinced that this tool is easy to use. But you might still be a bit undecided and might harbor a slight suspicion: Of course, ABAP Unit is uncomplicated to handle, but what it does is very elementary indeed. Why should I bother to write ten lines of test code to check something I can see at a glance? Does it pay at all to write such simple tests?

Regarding our frugal Percentages program with its minimal form, these objections do not seem utterly pointless. But, first you should remember that the Percentages-report containing the faulty form worked properly. It was only detected by the ABAP Unit test that the report yielded a correct output in the end only by accident and that the form itself was programmed incorrectly.

As a matter of fact, the real strong use cases for ABAP Unit tests are more complex programs, where you want to run a whole battery of small tests at the touch of one button after each modification. This way, you can easily detect side effects when minor changes in one part of a program affect another part which worked correctly so far. I will give you an example for this in part two of this spotlight on ABAP Unit.