Skip to Content

This is part 4 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 1A Spotlight on ABAP Unit Part 2, A Spotlight on ABAP Unit Part 3, A Spotlight on ABAP Unit Part 5.

In this weblog I would like to tell you something more about the ABAP Unit result display. By showing the result display of the flight example from a former weblog, I will explain to you which information you can draw from this display. One way to start the test is the menu path: Class->Unit Test in the class builder.

The ABAP Unit Result View

Once we test our example program we get the following result: The left side presents a tree with hierarchical order of all the test classes and test methods in the test task of the program unit we test, which can be a function module, a global class or a report as in our example. Under the name of the program, are the test classes, and below each test class are the test methods belonging to this class. In our example we had one test class with five test methods. So the tree looks like this:

!https://weblogs.sdn.sap.com/weblogs/images/266/Complex_Left.png|height=234|style=border-width:1px; border-style:solid; border-color:#000060|alt=image|align=left|width=408|src=https://weblogs.sdn.sap.com/weblogs/images/266/Complex_Left.png!

The red traffic lights indicate two critical errors in the global class cl_te4h_aunit_flights, two in the class TEST_Flights including one each in the methods add_flight and add_existing_flight. There are no exceptions, no runtime errors and no warnings. The level of the error is critical, because this is the default level, and we have not passed the optional parameter level to the method assert_equals.

The right side presents the total number of errors sorted by level (passed by the optional parameter LEVEL, which indicates how severe the error is: fatal, critical or tolerable). On the lower right you see the detail analysis pane.

image

Looking at the highlighted error, you realize at once: the information shown in the list at the top is the text we passed to the parameter msg of the method assert_equals of the test method add_flight of the class test_flights. The detail analysis pane below gives you more details about the error: the expected and actual value and the name of the method where the error occurred.

Keep in mind: Always pass a meaningful description of what went wrong to the msg-parameter of the method assert_equals. Otherwise, some days later, you will probably still agree that 180 does not equal 200, but you will not have the slightest idea of what this means and what the error is about.

Tracking Down the Source of an Error

A double click on the line under the node named “Stack” will take you to the line in the code where the mistake originated from. It is the local test method add_flight which in turn calls the public method add_flight. The next step requires some analysis. You have to find out why this method could not add a flight. I have explained this in the first weblog: Because the internal table has the unique key price, you cannot add another flight with a price that is already stored in some line in the internal table.

But how can we get a list sorted by price while avoiding the error we have seen? We just use an internal table in the report for the display of the data and sort this table by price. We run the ABAP Unit test again, and this time we see

image

in the status bar of the program instead of the ABAP Unit result screen. Apparently, a test result without error is only displayed in the status bar.

A Glimpse of other useful ABAP Unit features    

Apropos the internal table I just mentioned, let me present a nice and time saving feature of ABAP Unit for table comparison. If your assertion methods test the equality of two internal tables and the assertion fails, the detail pane does not stop at telling you that the two tables differ. It gives you comprehensive information about where and how the two tables are different. If you have ever compared two internal tables with about 100 lines in the debugger, you can appreciate how much time this feature can save.

Of course, there are far more features in ABAP Unit, more parameters in the method assert_equals and a whole bunch of service methods in the class cl_aunit_assert, which serve different purposes. To learn more about all these features and more interesting information on ABAP Unit you can attend the forthcoming article in the SAP Professional Journal on ABAP Unit which treats the topic in far more depth than I do here in these weblogs.

I will restrict myself in a last forthcoming weblog in this series to answering some common objections to unit testing. There are always some reasons at hand why not to write tests. I will show that at second sight they are not convincing. So there will be no pretext to refrain from writing units tests on a large scale, once you have read the next weblog on ABAP Unit.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply