Resources Blog Integration Tests With Maven (Part 2): Test Coverage Reports

Integration Tests With Maven (Part 2): Test Coverage Reports

In the previous article, we demonstrated one way of running integration tests with Maven. In this article, we will demonstrate how to measure the test coverage of both integration and unit tests.

We will be using Emma to measure and report the coverage. EMMA is an open-source toolkit for measuring and reporting Java code coverage.

Unit test coverage

Let's start by generating a coverage report for unit tests only. This will require 2 new plugins to be added to our pom. The first one:


This plugin will instrument classes at target/generated-class/emma/classes, this won't change the original classes at target/classes. Then, we must tell surefire plugin to look for classes at new location:



At this point, we do 50% of code coverage. Mainly because the psvm ( public static void main ) is never executed.

Here is the EMMA text report. Emma does produce xml and html reports in addition to this simple text report:

[EMMA v2.0.5312 report, generated Fri Jun 12 15:43:28 BRT 2009]

[class, %]	[method, %]	[block, %]	[line, %]	[name]
100% (1/1)	67%  (2/3)!	56%  (10/18)!	50%  (4/8)!	all classes

Note: at this point no report is generated, we will configure report generation after integration tests coverage reports are in place. Once you run Surefire, you may notice the in the project root directory. This file contains the coverage result in a binary format used by Emma.

Integration test coverage

So far, we have the unit tests results. As I demonstrated in the previous article in this series, the integration tests need the project artifact to run, so, we need to instrument this jar in order to get coverage result on ITs. Let's see the pom:





Note that is using a different plugin: emma4it-maven-plugin. This plugin provides some additional goals for instrumenting integrations tests. For this project we use instrument-project-artifact goal. This goal will add Emma instrumentation into the project jar. This is specific to tests running on integration-test phase, because it does requires that the packaged artifact be instrumented.

There is also the configuration appendEmma. When true, this goal will shade the Emma jar into the instrumented jar. This is very useful to test jars that will be launched from command line, like this project.

[EMMA v2.0.5312 report, generated Fri Jun 12 16:05:45 BRT 2009]

[class, %]	[method, %]	[block, %]	[line, %]	[name]
100% (1/1)	100% (3/3)	89%  (16/18)	88%  (7/8)	all classes

At this point we have a very decent code coverage, almost 90%, 7 of 8 lines of code, and on this project it is not possible to get 8/8. And why is that? System.exit(). when this line is invoked nothing else is executed, that includes Emma instrumented code, so Emma won't be able to know if System.exit() was executed, our integration tests catch that, because we check the exit code of the process, but Emma can't do the same.

Test Coverage Report

At this point we have all coverage data stored at, in Emma binary format. Let's now convert that into something that is more readable.

Add the following execution on emma4it-maven-plugin:




Now the text, HTML, and XML reports are generated at target/site/emma.

Emma HTML coverage report

That is it for part 2. On the next part, I will show some ideas about testing more complex projects like flexmojos and nexus.

Picture of Marvin Froeder

Written by Marvin Froeder

Over the past 11 years, Marvin has worked for several startups, most notably at The Last Pickle, ContaAzul, and Sonatype, where he was a Java Developer.