Understanding the Code Coverage Display in the ABAP Unit Browser

Use

This section explains the code coverage display in the ABAP Unit Browser. This display offers a subset of the fields and functions offered by the Detail Display in the Coverage Analyzer (transaction SCOV). The displays are different enough that we offer a separate description of the detail display in the ABAP Unit Browser.

Process

The code coverage display might look like the illustration below. The illustration uses a layout that includes all of the most useful fields.

Figure 1: Code Coverage Display for a Favorite in the ABAP Unit Browser

Programs displayed: The Favorites display shows all of the programs from which components were called by the unit tests in the Favorite. The metrics show the code coverage by the unit tests alone. Other coverage statistics already recorded by the Coverage Analyzer are ignored.

Only a Favorite, defined in the ABAP Unit Browser, offers this display of code coverage in isolation. The Browser display for unit tests run by program or package include more programs in the display and include additional code coverage data as well.

Key fields in the display: In the sample display:

The two status icons are set according to the coverage criteria specified in the Coverage Analyzer for procedure and statement coverage.

In this case, some of the ABAP Unit tests for these function groups were not run. Or the ABAP Unit tests need to be extended and refined to exercise more of the code in the function modules.
The Coverage fields give you precise information on the code coverage at the procedure, branch, and statement levels produced by the ABAP Unit tests.
The Summation fields give you some idea of the size of the code being tested.

For example, the unit tests achieve a Branch Coverage of 7.3%. With a total of more than 3700 branches in the code of the function group, this means that considerable effort will likely be required to achieve a satisfactory branch coverage.

Here is a brief discussion of standards for code coverage.

Drilling Down to Analyze Code Coverage by Processing Block

Unsatisfactory code coverage results like those above tell you that you need to improve your unit tests. But they do not tell you what you need to do to improve the code coverage achieved by the unit tests.

Fortunately, you can double-click on a line in the display to drill down to the level of the processing blocks in a program. And you can drill down farther to see the actual code coverage at the statement level.

Figure 2: Drilldown to Code Coverage by Processing Block

Drilling down to the processing blocks of function group SALC shows quickly how the code coverage of this legacy code could be improved. Many of the function modules of the function group are not exercised at all by the existing unit tests. It should be a relatively simple matter to add new unit tests for the function modules that are currently not tested. Function modules offer, after all, well-defined APIs that often are easily supplied with parameters to simulate normal and error conditions.

The drill down display also shows the test status of form routines. You can quickly identify untested or inadequately tested routines and provide unit tests for them.

Drilling Down to Analyze Code Coverage by Statement

In the drill down display above, you may notice that the branch coverage of some of the tested function modules is quite low. Three of the function modules have a branch coverage in the twenties.

Shouldn't the main path through the code cover more branching decisions? Or is the code is full of plausibility checks that are not reached by the code?

How can you determine whether the code coverage is adequate in these function modules, and how it can be improved?

To answer questions about code coverage in detail and make judgments about the level of code coverage that is acceptable, you can drill down to see code coverage by branch and statement.

Figure 3: Drilldown to code coverage by statement

The display clarifies what the problem is with branch coverage in this function module. The unit test currently is not able to produce error results from a function called within the tested function module. If you select a conditional statement with the cursor, the display shows conditions that were tested. In this case, the conditional IF statements were resolved only to 'false'. .

This information lets you make a well-informed decision about the unit test. You can see that you can improve the branch coverage if you can provoke errors in SALC_CACHE_GET_MTE_BY_CLASS. If you know the code, then you can judge whether the function module can be manipulated from outside or represents an unbreakable dependency - you cannot manipulate its results without changing internal code. If the function call presents unbreakable dependencies, then you can decide whether it is enough to test the error cases directly, in a unit test for SALC_CACHE_GET_MTE_BY_CLASS. Or whether it is necessary to re-factor this code in order to break the dependency on SALC_CACHE_GET_MTE_BY_CLASS: