Report” checkbox, you should see something like Figure 6.13, “Configuring the test coverage metrics
in Jenkins”.
Figure 6.13. Configuring the test coverage metrics in Jenkins
The first and most important field here is the path to the Cobertura XML data that we generated. Your
project may include a single coverage.xml file, or several. If you have a multimodule Maven project,
for example, the Maven Cobertura plugin will generate a separate coverage.xml file for each module.
The path accepts Ant-style wildcards, so it is easy to include code coverage data from several files. For
any Maven project, a path like **/target/site/cobertura/coverage.xml will include all of the
code coverage metrics for all of the modules in the project.
There are actually several types of code coverage, and it can sometimes be useful to distinguish between
them. The most intuitive is Line Coverage, which counts the number of times any given line is executed
during the automated tests. “Conditional Coverage” (also referred to as “Branch Coverage”) takes into
account whether the boolean expressions in if statements and the like are tested in a way that checks all
the possible outcomes of the conditional expression. For example, consider the following code snippet:
if (price > 10000) {
managerApprovalRequired = true;
}To obtain full Conditional Coverage for this code, you would need to execute it twice: once with a value
that is more than 10,000, and one with a value of 10,000 or less.
Other more basic code coverage metrics include methods (how many methods in the application were
exercised by the tests), classes and packages.