Verifying End-to-End Test Code Coverage Using Jacoco Agent

DZone 's Guide to

Verifying End-to-End Test Code Coverage Using Jacoco Agent

End-to-end testing is important to ensure the quality of the product you'll be shipping. See how to implement an end-to-end testing scenario in this walkthrough.

· DevOps Zone ·
Free Resource

Fact: end-to-end tests are critical if you want to make sure your software works as it should. To be 100% sure that you covered every (or almost every) possible branch of your business code, it is worth it to check what code has been invoked after your E2E suite finished successfully. The solution I am going to present may be much easier if you are able to stand up your application locally. Sometimes, though, it is not the case.

In this scenario, we are going to start two instances of a web application at the remote servers, with code invocation recording turned on. Next, we are going to run integration tests pointing to them one after another with different parameters, to test different paths. After the tests are done, we are going to pull the data from these servers to localhost, merge it and transform it to HTML report.

We are going to test this simple REST controller:

public class ExampleController {

    @GetMapping(path = "/test")
    public int exampleMethod(@RequestParam int parameter) {
        if(parameter > 10) {
            return invokeThisBranch(parameter);
        } else {
            return invokeAnotherBranch(parameter);

    private int  invokeThisBranch(int parameter) {
        System.out.println("Taking this branch..");
        if(parameter < 10) {
            System.out.println("This cannot be tested..");
        return 3;

    private int invokeAnotherBranch(int parameter) {
        System.out.println("Taking another branch..");
        return 3;

To make things simple, we will run two instances of the same application on our local machines (on different ports). Before we do that, we need to download Jacoco agent from this link. Remember that the version must match the version of your Jacoco plugin in Maven. This agent will be attached to JVM and record the code coverage. The problem is that you need to push it to your remote server manually (if you find a way to automate this clean way, let me know). If you are using IntelliJ, add this to VM options in your Run Configuration (or add this to startup script on a remote server):


By specifying the output as a tcpserver and providing a port, you are enabling further connection from the Maven plugin, which will download a data file (jacoco-it.exec).

Our test suite contains one test, which will cause different methods to be invoked depending on the parameter value.

public class TestCoverageExampleApplicationTests {

    private TestRestTemplate testRestTemplate = new TestRestTemplate();

    public void anotherBranchTest() {
        int appPort =  Integer.parseInt(System.getProperty("app.port"));
        int parameter = Integer.parseInt(System.getProperty("parameter"));

        Integer result = testRestTemplate.getForObject(
                "http://localhost:" + appPort + "/test?parameter=" + parameter, Integer.class);


We want to make sure that even though the code coverage was spread among instances, we will merge it correctly to be able to see the whole picture. Let’s run the test - different paths for different instance:

mvn test -Dapp.port=8080 -Dparameter=5
mvn test -Dapp.port=8081 -Dparameter=15

Before we generate a coverage report, we need to configure Jacoco plugins in the pom.xml file. The full version can be found on my GitHub account:

                        <fileSet implementation="org.apache.maven.shared.model.fileset.FileSet">
                        <taskdef name="report" classname="org.jacoco.ant.ReportTask">
                            <classpath path="${basedir}/target/jacoco-jars/org.jacoco.ant.jar"/>
                        <mkdir dir="${basedir}/target/coverage-report"/>
                                <fileset dir="${basedir}">
                                    <include name="target/jacoco-it*.exec"/>
                            <structure name="jacoco-multi Coverage Project">
                                <group name="jacoco-multi">
                                        <fileset dir="target/classes"/>
                                    <sourcefiles encoding="UTF-8">
                                        <fileset dir="src/main/java"/>
                            <html destdir="${basedir}/target/coverage-report/html"/>
                            <xml destfile="${basedir}/target/coverage-report/coverage-report.xml"/>
                            <csv destfile="${basedir}/target/coverage-report/coverage-report.csv"/>

Let’s create an automated script for coverage report generation:

mvn jacoco:dump@pull-test-data -Dapp.host=localhost -Dapp.port=36320 -Dskip.dump=false
mvn jacoco:dump@pull-test-data -Dapp.host=localhost -Dapp.port=36321 -Dskip.dump=false
mvn jacoco:merge@merge-test-data -Dskip.dump=false
mvn antrun:run@generate-report -Dskip.int.tests.report=false

The script will pull the data files from two remote servers (localhost, in our case), merge them into one file, and then generate a report from it.

The final report is a joy to analyze:

Image title

Our class:

Image title

As you can see, even though different code was invoked in different instances, the final report contains both paths.

Some real-world problems you may encounter:

  • If you use bytecode manipulators like Lombok or AspectJ, Jacoco won’t be able to find a source code that matches the invoked lines; you can use auto-value or immutables instead of Lombok for some use cases and spring-aop instead of AspectJ.
  • If you write your tests in Spock and you want to upload your jacoco-it.exec files to Sonar to show the code coverage there, you have to make sure Groovy’s expressive method names will be correctly transformed in the failsafe report - you need to add org.sonar.java.jacoco.JUnitListener as a listener.

The full code can be found on my GitHub account.

code coverage, devops, integration testing, jacoco, testing

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}