Maven Multi-Module Project Coverage With Jacoco

1. Overview

In this tutorial, we’ll build a Maven multi-module project. In this project, the services and controllers will be in different modules. Then, we’ll write some tests and use Jacoco to calculate the code coverage.

2. Service Layer

First, let’s create the service layer of our multi-module application.

2.1. Service Class

We’ll create our service and add a couple of methods:

@Service
class MyService {

    String unitTestedOnly() {
        return "unit tested only";
    }

    String coveredByUnitAndIntegrationTests() {
        return "covered by unit and integration tests";
    }

    String coveredByIntegrationTest() {
        return "covered by integration test";
    }

    String notTested() {
        return "not tested";
    }

}

As their names indicate:

• a unit test located in the same layer will test the method unitTestedOnly()
• a unit test will test coveredByUnitAndIntegrationTests(). An integration test in the controller module will also cover this method’s code
• an integration test will cover coveredByIntegrationTest(). However, no unit test will test this method
• No test will cover the method notTested()

2.2. Unit Tests

Let’s now write the corresponding unit tests:

class MyServiceUnitTest {

    MyService myService = new MyService();
    
    @Test
    void whenUnitTestedOnly_thenCorrectText() {
        assertEquals("unit tested only", myService.unitTestedOnly());
    }

    @Test
    void whenTestedMethod_thenCorrectText() {
        assertEquals("covered by unit and integration tests", myService.coveredByUnitAndIntegrationTests());
    }

}

The tests are simply checking that the method’s output is as expected.

2.3. Surefire Plugin Configuration

We’ll use the Maven Surefire plugin to run the unit tests. Let’s configure it inside the service’s module pom.xml:

<plugins>
    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>3.2.5</version>
    <configuration>
    <includes>
        <include>**/*Test.java</include>
    </includes>
    </configuration>
    </plugin>
</plugins>

3. Controller Layer

We’ll now add a controller layer in our multi-module application.

3.1. Controller Class

Let’s add the controller class:

@RestController
class MyController {

    private final MyService myService;

    public MyController(MyService myService) {
        this.myService = myService;
    }

    @GetMapping("/tested")
    String fullyTested() {
        return myService.coveredByUnitAndIntegrationTests();
    }

    @GetMapping("/indirecttest")
    String indirectlyTestingServiceMethod() {
        return myService.coveredByIntegrationTest();
    }

    @GetMapping("/nottested")
    String notTested() {
        return myService.notTested();
    }

}

The fullyTested() and indirectlyTestingServiceMethod() methods will be tested by integration tests. As a result, those tests will cover the two service methods coveredByUnitAndIntegrationTests() and coveredByIntegrationTest(). On the other hand, we’ll write no test for notTested().

3.2. Integration Tests

We can now test our RestController:

@SpringBootTest(classes = MyApplication.class)
@AutoConfigureMockMvc
class MyControllerIntegrationTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    void whenFullyTested_ThenCorrectText() throws Exception {
        mockMvc.perform(MockMvcRequestBuilders.get("/tested"))
          .andExpect(MockMvcResultMatchers.status()
            .isOk())
          .andExpect(MockMvcResultMatchers.content()
            .string("covered by unit and integration tests"));
    }

    @Test
    void whenIndirectlyTestingServiceMethod_ThenCorrectText() throws Exception {
        mockMvc.perform(MockMvcRequestBuilders.get("/indirecttest"))
          .andExpect(MockMvcResultMatchers.status()
            .isOk())
          .andExpect(MockMvcResultMatchers.content()
            .string("covered by integration test"));
    }

}

In these tests, we start an application server and send it requests. Then, we check that the output is correct.

3.3. Failsafe Plugin Configuration

We’ll use the Maven Failsafe plugin to run the integration tests. The last step is to configure it inside the controller’s module pom.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>3.1.2</version>
    <executions>
        <execution>
            <goals>
                <goal>integration-test</goal>
                <goal>verify</goal>
            </goals>
	</execution>
        </executions>
    <configuration>
        <includes>
            <include>**/*IntegrationTest.java</include>
        </includes>
    </configuration>
</plugin>

4. Aggregating Coverage via Jacoco

Jacoco (Java Code Coverage) is a tool used in Java applications to measure code coverage during testing. Let’s now compute our coverage report.

4.1. Preparing Jacoco Agent

The prepare-agent phase sets up the necessary hooks and configuration so that Jacoco can track the executed code while running tests. This configuration is required before we run any tests. Thus, we’ll add the preparation step directly to the parent pom.xml:

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.11</version>
    <executions>
        <execution>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
    </executions>
</plugin>

4.2. Gathering Tests Results

To gather the test coverage, we’ll create a new module aggregate-report. It contains only a pom.xml and has dependencies on the two previous modules.

Thanks to the preparation phase, we can aggregate the reports from every module. It’s the job of the report-aggregate goal:

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.8</version>
    <executions>
        <execution>
            <phase>verify</phase>
            <goals>
                <goal>report-aggregate</goal>
            </goals>
            <configuration>
                <dataFileIncludes>
                    <dataFileInclude>**/jacoco.exec</dataFileInclude>
                </dataFileIncludes>
                <outputDirectory>${project.reporting.outputDirectory}/jacoco-aggregate</outputDirectory>
            </configuration>
        </execution>
    </executions>
</plugin>

We can now run the verify goal from the parent module:

$ mvn clean verify

At the end of the build, we can see that Jacoco generates the report in the target/site/jacoco-aggregate folder of the aggregate-report submodule.

Let’s open the index.html file to have a look at the results.

To begin, we can navigate to the report for the controller class:

As expected, the constructor and the fullyTested() and indirectlyTestingServiceMethod() methods are covered by the tests, whereas notTested() isn’t covered.

Let’s now have a look at the report for the service class:

This time, let’s focus on the coveredByIntegrationTest() method. As we know, no test in the service module tests this method. The only test that passes through this method’s code is inside the controller module. However, Jacoco recognized that there is a test for this method. In this case, the word aggregation takes its whole meaning!

5. Conclusion

In this article, we created a multi-module project and gathered the test coverage thanks to Jacoco.

Let’s recall that we need to run the preparation phase before the tests, while the aggregation takes place after them. To go further, we can use a tool like SonarQube to get an excellent overview of the coverage result.