Frequently asked questions about code coverage

This topic contains answers to frequently asked questions about code coverage.

Q. What causes a line to be partially covered (shown with a yellow indicator)?

A. A line will be indicated as partially covered if not all branches through the code are run.

Following are a couple of examples:

  1. Exception handlers: try { methodA() // methodA throws Exception } catch (Exception e) {..}

    The line that calls methodA is partially covered because there are two paths: either an exception is thrown and caught or an exception is not thrown and the program runs normally. In the case where the exception is not thrown, partial coverage is indicated because the catch is never run.

  2. Shared constructor code:

    Artwork for staff_class_example1

    In the above example, line 4 is marked as partially covered. Note that the instance variable initialization code is run no matter which constructor is used to create the object instance. The compiler puts the initialization code in both of the constructors. The above code is therefore roughly equivalent to:

    Artwork for staff_class_example1

    Since we only use one constructor, the other execution path is not run and partial coverage is indicated.

Q. In the code coverage reports, why are the total lines reported for a package not always equal to the totals shown for the classes in that package?

A. When we report the total lines in a package we factor out any lines shared between methods so they are not double counted.

Q. Why are class definitions (for example public class Foo {..}) indicated as uncovered (red) or partially covered (yellow)?

A. If your class does not have an explicit default constructor, the compiler will generate one for you and since it is implicit it may be associated with that line of code. Secondly, if you have any static initialization code (for example, static fields), the compiler generates static initialization blocks which may also be associated with that line.

Q. Why do the coverage indicators in the Package Explorer appear in red even though the percentage covered exceeds the acceptable coverage level?

A. When more than one acceptance criterion is set (for example, method AND block), the indicator will be displayed in red if any one of the criterion is not met. Acceptance criteria are set by selecting (code coverage properties) and then enabling indicators and percentages. Displayed coverage indicators are set by selecting (code coverage preferences) and then enabling the indicators (method, block, etc.). The color will be determined by the criteria set using the properties page and not by the preferences page.

Q. What lines are not counted in Code Coverage?

A. The following are not counted as covered, uncovered or partially covered and are not used to calculate the percentage covered:

  • Lines containing comments, method declarations, variable declarations (for example, int i;)
  • Class declarations for a class with constructors
  • Open brackets of methods
  • Close brackets for methods with return statements
  • Else by itself (excluding else (statement))
  • Empty lines
  • Boolean expressions with constants such as if(true), if(false), while(true).
  • Annotations, interfaces and abstract methods

Q. What do you mean by blocks in block coverage?

A. An executable unit begins at the start of every basic block, and at every byte code whose source line number is different from the previous byte code. A basic block is a region of byte code instructions that cannot be branched out of, or branched into. When the first instruction in a basic block runs, all of the instructions are run, so the instructions are considered to be a single group.

Basic blocks end with instructions such as branch, call, throw, and return.

Q. Why when I am debugging code coverage enabled applications does the debugger step into llc_probe.class rather than the expected method?

A. This is because of the way code coverage data is collected. To work around it, you need to use the step filters:

  • Enable code coverage.
  • Go to Preferences > Java > Debug > Step Filtering
  • Check Use Step Filters.
  • Click Add Filter. In the dialog, enter "llc_probe*" and press OK to add it to the list of step filters.
  • Click Add Filter. In the dialog, enter "com.ibm.rational.llc.engine*" and press OK to add it to the list of step filters.
  • Click Add Filter. In the dialog, enter "com.ibm.jvm*" and press OK to add it to the list of step filters.
  • Select the java* and sun* entries from the list of step filters.

Feedback