| 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>
|
| Radek Liba | ad5fbc9 | 2009-10-26 13:26:53 +0000 | [diff] [blame] | 32 | A basic block – mostly just referred to as <i>block</i> in the APIs and
|
| 33 | reports – represents a consecutive sequence of byte code instructions
|
| 34 | and is a unit that will either execute completely or not all. The single
|
| 35 | exception from this definition occurs when the java exception mechanism comes
|
| 36 | to action (i.e. a java exception "flies"). This always interrupts the current
|
| 37 | blocks execution. The boundaries between blocks are
|
| Marc R. Hoffmann | c4b2078 | 2009-10-02 13:28:46 +0000 | [diff] [blame] | 38 | </p>
|
| 39 |
|
| 40 | <ul>
|
| 41 | <li>return instructions,</li>
|
| 42 | <li>throw instructions,</li>
|
| 43 | <li>(conditional) jump instructions and</li>
|
| 44 | <li>target labels referred from jump, try/catch or switch instructions.</li>
|
| 45 | </ul>
|
| 46 |
|
| 47 | <p>
|
| 48 | The JaCoCo instrumentation mechanism inserts a probe at the end of every
|
| Radek Liba | ad5fbc9 | 2009-10-26 13:26:53 +0000 | [diff] [blame] | 49 | block. When the probe gets executed the block is considered executed.
|
| 50 | This results in the major drawback of basic block based probes:
|
| Marc R. Hoffmann | c4b2078 | 2009-10-02 13:28:46 +0000 | [diff] [blame] | 51 | </p>
|
| 52 |
|
| 53 | <p class="hint">
|
| Radek Liba | ad5fbc9 | 2009-10-26 13:26:53 +0000 | [diff] [blame] | 54 | Blocks that encounter an exception somewhere in the middle of their execution
|
| 55 | will be considered as not executed. This is correct as the block actually
|
| 56 | didn't get executed but JaCoCo won't be able to tell which lines of the block
|
| 57 | executed and which didn't.
|
| Marc R. Hoffmann | c4b2078 | 2009-10-02 13:28:46 +0000 | [diff] [blame] | 58 | </p>
|
| 59 |
|
| 60 | <p>
|
| 61 | Beside this, basic block code coverage has been proven to work very
|
| 62 | efficiently even with huge applications under test. The reasons are that the
|
| 63 | blocks can be easily determined at instrumentation time. The amount of
|
| 64 | inserted probes offer a good tradeoff between runtime overhead and report
|
| 65 | granularity. And last but not least basic blocks can be determined even if the
|
| 66 | class files have not been compiled in debug mode and therefore do not contain
|
| 67 | any source line information. Therefore all coverage counters except the line
|
| 68 | counter will work also in this case and provide useful coverage information
|
| 69 | e.g. for binary third party libraries.
|
| 70 | </p>
|
| 71 |
|
| 72 | <h2>Instructions</h2>
|
| 73 |
|
| 74 | <p>
|
| 75 | For each block the number of included byte code instructions can be easily
|
| 76 | determined. The instruction counter summarizes the number of single byte code
|
| Radek Liba | ad5fbc9 | 2009-10-26 13:26:53 +0000 | [diff] [blame] | 77 | instructions that belong to executed blocks. As blocks may be of different
|
| 78 | length, instructions give a good measure of block size and can serve as a
|
| Marc R. Hoffmann | c4b2078 | 2009-10-02 13:28:46 +0000 | [diff] [blame] | 79 | replacement when no line information is available.
|
| 80 | </p>
|
| 81 |
|
| 82 | <h2>Lines</h2>
|
| 83 |
|
| 84 | <p>
|
| 85 | For all class files that have been compiled in debug mode with source line
|
| Radek Liba | ad5fbc9 | 2009-10-26 13:26:53 +0000 | [diff] [blame] | 86 | information, coverage information for individual lines can be derived from
|
| Marc R. Hoffmann | c4b2078 | 2009-10-02 13:28:46 +0000 | [diff] [blame] | 87 | basic blocks. Each block may span one ore multiple lines of source code. On
|
| Radek Liba | ad5fbc9 | 2009-10-26 13:26:53 +0000 | [diff] [blame] | 88 | the other hand a single line of source may belong to multiple blocks. A source
|
| 89 | line is considered executed when at least one block that includes this line
|
| Marc R. Hoffmann | c4b2078 | 2009-10-02 13:28:46 +0000 | [diff] [blame] | 90 | has been executed.
|
| 91 | </p>
|
| 92 |
|
| 93 | <p>
|
| 94 | Due to the fact that a single line may belong to more that one block
|
| 95 | <i>partial</i> coverage can happen if some of the blocks are executed while
|
| 96 | others are not. This is typically the case with boolean expressions. While
|
| Radek Liba | ad5fbc9 | 2009-10-26 13:26:53 +0000 | [diff] [blame] | 97 | partially covered lines are seen as executed due to the definition in the
|
| Marc R. Hoffmann | c4b2078 | 2009-10-02 13:28:46 +0000 | [diff] [blame] | 98 | previous paragraph, they are highlighted in yellow color in the coverage
|
| 99 | reports.
|
| 100 | </p>
|
| 101 |
|
| 102 | <h2>Methods</h2>
|
| 103 |
|
| 104 | <p>
|
| 105 | Each non-abstract method consists of at least one block. A method is
|
| 106 | considered as executed when at least one block has been executed. As JaCoCo
|
| 107 | works on byte code level also constructors and static initializers are counted
|
| 108 | as methods. Some of these methods may not have a direct correspondence in Java
|
| Radek Liba | ad5fbc9 | 2009-10-26 13:26:53 +0000 | [diff] [blame] | 109 | source code, like implicit and thus generated default constructors or initializers
|
| Marc R. Hoffmann | c4b2078 | 2009-10-02 13:28:46 +0000 | [diff] [blame] | 110 | for constants.
|
| 111 | </p>
|
| 112 |
|
| 113 | <h2>Classes</h2>
|
| 114 |
|
| 115 | <p>
|
| Radek Liba | ad5fbc9 | 2009-10-26 13:26:53 +0000 | [diff] [blame] | 116 | A class is considered as executed when at least one of its methods has been
|
| Marc R. Hoffmann | c4b2078 | 2009-10-02 13:28:46 +0000 | [diff] [blame] | 117 | executed. Note that JaCoCo considers constructors as well as static
|
| 118 | initializers as methods. As Java interface types may contain static
|
| 119 | initializers such interfaces are also considered as executable classes.
|
| 120 | </p>
|
| 121 |
|
| 122 |
|
| 123 |
|
| 124 | <div class="footer">
|
| 125 | <div class="versioninfo"><a href="@HOMEURL@">JaCoCo</a> @VERSION@</div>
|
| 126 | <a href="license.html">Copyright</a> © 2009 Mountainminds GmbH & Co. KG and Contributors
|
| 127 | </div>
|
| 128 |
|
| 129 | </body>
|
| 130 | </html> |