| Marc R. Hoffmann | c4b2078 | 2009-10-02 13:28:46 +0000 | [diff] [blame^] | 1 | <?xml version="1.0" encoding="ISO-8859-1" ?>
|
| 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
| 3 | <html xmlns="http://www.w3.org/1999/xhtml" lang="en">
|
| 4 | <head>
|
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
|
| 6 | <link rel="stylesheet" href=".resources/doc.css" charset="ISO-8859-1" type="text/css" />
|
| 7 | <title>JaCoCo - Coverage Counter</title>
|
| 8 | </head>
|
| 9 | <body>
|
| 10 |
|
| 11 | <div class="breadcrumb">
|
| 12 | <a href="../index.html" class="el_session">JaCoCo</a> >
|
| 13 | <a href="index.html" class="el_group">Documentation</a> >
|
| 14 | <span class="el_source">Coverage Counters</span>
|
| 15 | </div>
|
| 16 |
|
| 17 | <h1>Coverage Counters</h1>
|
| 18 |
|
| 19 | <p>
|
| 20 | JaCoCo uses a set of different counters to calculate coverage metrics. The
|
| 21 | foundation of all counters are so called <i>basic blocks</i>. All other
|
| 22 | counters are derived from the <i>basic block</i> coverage information. While
|
| 23 | JaCoCo counters appear to be closely related to Java source code they are
|
| 24 | actually only derived from Java class files. In cases where the Java compiler
|
| 25 | creates so called <i>synthetic</i> code to reflect certain Java language
|
| 26 | constructs counters may therefore show unexpected results.
|
| 27 | </p>
|
| 28 |
|
| 29 | <h2>Basic Blocks</h2>
|
| 30 |
|
| 31 | <p>
|
| 32 | Basic blocks – mostly just referred to as <i>blocks</i> in the APIs and
|
| 33 | reports – are consecutive sequences of byte code instructions that will
|
| 34 | normally only executed on-block. The boundaries between blocks are
|
| 35 | </p>
|
| 36 |
|
| 37 | <ul>
|
| 38 | <li>return instructions,</li>
|
| 39 | <li>throw instructions,</li>
|
| 40 | <li>(conditional) jump instructions and</li>
|
| 41 | <li>target labels referred from jump, try/catch or switch instructions.</li>
|
| 42 | </ul>
|
| 43 |
|
| 44 | <p>
|
| 45 | The JaCoCo instrumentation mechanism inserts a probe at the end of every
|
| 46 | block. When the probe gets executes the block can be considered as executed.
|
| 47 | Unfortunately the opposite does not hold true: Exceptions might interrupt a
|
| 48 | block somewhere in the middle and the probe will not get executed. This
|
| 49 | results in the major drawback of basic block based probes:
|
| 50 | </p>
|
| 51 |
|
| 52 | <p class="hint">
|
| 53 | Blocks that encounter an exception somewhere in the middle will be considered
|
| 54 | as not executed.
|
| 55 | </p>
|
| 56 |
|
| 57 | <p>
|
| 58 | Beside this, basic block code coverage has been proven to work very
|
| 59 | efficiently even with huge applications under test. The reasons are that the
|
| 60 | blocks can be easily determined at instrumentation time. The amount of
|
| 61 | inserted probes offer a good tradeoff between runtime overhead and report
|
| 62 | granularity. And last but not least basic blocks can be determined even if the
|
| 63 | class files have not been compiled in debug mode and therefore do not contain
|
| 64 | any source line information. Therefore all coverage counters except the line
|
| 65 | counter will work also in this case and provide useful coverage information
|
| 66 | e.g. for binary third party libraries.
|
| 67 | </p>
|
| 68 |
|
| 69 | <h2>Instructions</h2>
|
| 70 |
|
| 71 | <p>
|
| 72 | For each block the number of included byte code instructions can be easily
|
| 73 | determined. The instruction counter summarizes the number of single byte code
|
| 74 | instructions that belong to executed blocks. As blocks may have different
|
| 75 | lengths instructions represent the size of the blocks and can serve as a
|
| 76 | replacement when no line information is available.
|
| 77 | </p>
|
| 78 |
|
| 79 | <h2>Lines</h2>
|
| 80 |
|
| 81 | <p>
|
| 82 | For all class files that have been compiled in debug mode with source line
|
| 83 | information, coverage information for individual lines can be calculated from
|
| 84 | basic blocks. Each block may span one ore multiple lines of source code. On
|
| 85 | the other hand a single line of source my belong to multiple blocks. A source
|
| 86 | line is considered as executed when at least one block that includes this line
|
| 87 | has been executed.
|
| 88 | </p>
|
| 89 |
|
| 90 | <p>
|
| 91 | Due to the fact that a single line may belong to more that one block
|
| 92 | <i>partial</i> coverage can happen if some of the blocks are executed while
|
| 93 | others are not. This is typically the case with boolean expressions. While
|
| 94 | partially coverage lines are counted as executed due to the definition in the
|
| 95 | previous paragraph, they are highlighted in yellow color in the coverage
|
| 96 | reports.
|
| 97 | </p>
|
| 98 |
|
| 99 | <h2>Methods</h2>
|
| 100 |
|
| 101 | <p>
|
| 102 | Each non-abstract method consists of at least one block. A method is
|
| 103 | considered as executed when at least one block has been executed. As JaCoCo
|
| 104 | works on byte code level also constructors and static initializers are counted
|
| 105 | as methods. Some of these methods may not have a direct correspondence in Java
|
| 106 | source code, like implicitly generated default constructors or initializers
|
| 107 | for constants.
|
| 108 | </p>
|
| 109 |
|
| 110 | <h2>Classes</h2>
|
| 111 |
|
| 112 | <p>
|
| 113 | A class is considered as executed when at least one of its method has been
|
| 114 | executed. Note that JaCoCo considers constructors as well as static
|
| 115 | initializers as methods. As Java interface types may contain static
|
| 116 | initializers such interfaces are also considered as executable classes.
|
| 117 | </p>
|
| 118 |
|
| 119 |
|
| 120 |
|
| 121 | <div class="footer">
|
| 122 | <div class="versioninfo"><a href="@HOMEURL@">JaCoCo</a> @VERSION@</div>
|
| 123 | <a href="license.html">Copyright</a> © 2009 Mountainminds GmbH & Co. KG and Contributors
|
| 124 | </div>
|
| 125 |
|
| 126 | </body>
|
| 127 | </html> |