SKM IT World

Just another blog about IT

Test Coverage Reports For Maven Projects In SonarQube 8.3.x


Some years ago I write a blog post about how to generate test reports in SonarQube separate in test report for unit tests and for integration tests. Since SonarQube 6.2 the test report isn’t separate in these categories any more (see SonarQube’s blog post). SonarQube merges all test reports to one test report with an overall coverage. So how to configure JaCoCo Maven Plugin if you have separate your tests in unit tests (running by Maven Surefire Plugin) and integration tests (running by Maven Failsafe Plugin) in your Maven project.

In the following sections, a solution is presented that meets following criteria:

  • Maven is used as build tool.
  • The project can be a multi module project.
  • Unit tests and integration tests are parts of each module.
  • Test coverage is measured by JaCoCo Maven Plugin.

The road map for the next section is that firstly the Maven project structure is shown for the separation of unit and integration tests. Then the Maven project configuration is shown for having separate unit test runs and integration test runs.  After that, we have a look on the Maven project configuration for the test report generation that covers unit and integration tests. At the end, SonarQube’s configuration is shown for the test report visualization in the SonarQube’s dashboard.

Maven Project Structure

At first, we look at how a default Maven project structure looks like for a single module project.

├── pom.xml
├── src
│   ├── main
│   │   └── java
│   └── test
│       └── java

The directory src/main/java contains the production source code and the directory src/test/java contains the test source code. We could put unit tests and integration tests together in this directory. But we want to separate these two types of tests in separate directories. Therefore, we add a new directory called src/it/java. Then unit tests are put in the directory src/test/java and the integration tests are put in the directory src/it/java, so the new project structure looks like the following one.

├── pom.xml
├── src
│   ├── it
│   │   └── java
│   ├── main
│   │   └── java
│   └── test
│       └── java

Unit And Integration Test Runs

Fortunately, the unit test run configuration is a part of the Maven default project configuration. Maven runs these tests automatically if following criteria are met:

  • The tests are in the directory src/test/java and
  • the test class name either starts with Test or ends with Test or TestCase.

Maven runs these tests during the Maven’s build lifecylce phase test.

The integration test run configuration has to be done manually. It exists Maven plugins that can help. We want that the following criteria are met:

  • integration tests are stored in the directory src/it/java and
  • the integration test class name either starts IT or ends with IT or ITCase and
  • integrations tests runs during the Maven’s build lifecycle phase integration-test.

Firstly, Maven has to know that it has to include the directory src/it/java to its test class path. Here, the Build Helper Maven Plugin can help. It adds the directory src/it/java to the test class path.


The above code snippet has to be inserted into the section <project><build><plugins> in the project root pom.

Maven’s build lifecycle contains a phase called integration-test.  In this phase, we want to run the integration test. Fortunately, Maven Failsafe Plugins’ goal integration-test is bind to this phase automatically when it’s set up in the POM. If you want that the build fails when the integration tests fails then the goal verify also has to be added into the POM:


Again, the above code snippet also has to be inserted into the section <project><build><plugins> in the project root pom. Then Maven Failsafe Plugin runs the integration tests automatically, when their class name either starts with IT or ends with IT or ITCase.

Test Report Generation

We want to use the JaCoCo Maven Plugin for the test report generation. It should generate test reports for the unit tests and for the integration tests. Therefore, the plugin has to two separated agents, that have to be prepared. Then they generate the report during the test runs. The Maven’s build lifecycle contains own phases for preparation before the test phases (test and integration-test). The preparation phase for the test phase is called process-test-classes and the preparation phase for integration-test phase is called pre-integration-test. JaCoCo binds its agent to these phases automatically, when its goals prepare-agent and prepare-agent-integration are set up in the POM. But this is not enough. JaCoCo also has to create a report, so that SonarQube can read the reports for the visualization. Therefore, we have to add the goals report and report-integration in the POM:


Again, it is a part of the section <project><build><plugins>.

Now, we can run the goal mvn verify and our project is built inclusive unit and integration test and inclusive generating two test reports.

SonarQube Test Report Visualization

Now, we want to visualize our test reports in SonarQube. Therefore, we have to run the Sonar Maven 3 Plugin (command mvn sonar:sonar)  in our project after a successful build. So Sonar Maven Plugin knows where to upload the report, we have to configure our SonarQube instance in ~/.m2/setting.xml:

        <!-- Optional URL to server. Default value is http://localhost:9000 -->

When we open our project in the SonarQube dashboard, we see the overall test coverage report.


This blog describes how to generate test reports for a Maven build if unit tests and integration tests run separately. On GitHub, I host a sample project that demonstrate all configuration steps. As technical environment I use

  • Maven 3.6.3
  • Maven Plugins:
    • Maven Surefire Plugin
    • Maven Failsafe Plugin
    • Build Helper Maven Plugin
    • Jacoco Maven Plugin
    • Sonar Maven Plugin
  • SonarQube 8.3.1
  • Java 11


  1. Jacoco Maven plugin project site
  2. Maven Failsafe Plugin  project site
  3. Build Helper Maven Plugin project site
  4. SonarQube documentation about Test Coverage in common
  5. A sample Maven project on GitHub

2 thoughts on “Test Coverage Reports For Maven Projects In SonarQube 8.3.x

  1. I’m afraid that in my opinion you have gone down a little too deep into the “because it’s possible” rabbit hole.

    While I’m 100% on board with not mixing the code coverage of integration and unit tests, I maintain that the solution is to *not measure integration test coverage at all*.

    Your integration tests should cover the requirements (i.e. are there enough representative examples of the use cases your system should provide?) and the question of how much code they cover in order to do that is completely beside the point.

    It is easy to fall into the trap of measuring integration test coverage simply because the numbers are so easily attainable. Whenever we measure, we must let ourselves be guided by the question “is this relevant and in which way does it reflect on the quality of my software?” rather than simply measuring the things that are easy to measure.

    The moment you start measuring integration test coverage, the question is: What does this number tell me?

    Another question is: What is the desired/necessary coverage my integration tests should achieve?

    In case your answer is: 100% (which is the only valid coverage goal for unit tests), the question becomes: “Why have unit tests at all?”

    If your answer is any number below that (let’s assume 70%, just for the argument’s sake), the question becomes: “How do I ensure that I am testing the relevant 70% of the system?”

    So, do yourself a favour, configure JaCoCo to just measure the coverage of your unit tests and simply ignore the integration tests for the purposes of code coverage!


    • Thank you for your comment. I can understand you that it seems that I go down in a “because it’s possible” rabbit hole.

      I had two situations in my projects, where I needed this set up:

      1) Devs teams want to merge these both test report for “beautifying” the report (“Management said, the test coverage must be 90% in SonarQube”).
      2) The dev team uses the integration test phase for tests that need infrastructure like database etc.

      For the first situation, I agree with you. This is the worst motivation to do it.
      In the second situation, I’m fine with merging the test report because here integration tests could be for example repository tests including a database.

      IMHO, it’s a pity that SonarQube removed the distinction in the test reports between unit tests, integration tests and overall tests.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.