9

Test Coverage analysis (with JaCoCo and Sonar) for your Spring Boot app

One of the main metrics for a software project is Test Coverage: if done properly, it gives you a quick picture about how much code is ‘protected’ by tests.

In this article, I’ll show you how to use a minimal configuration for including JaCoCo in our Spring Boot application, and how to process this information with Sonar.

Why JaCoCo?

The JaCoCo library is one of most extended solutions for measuring coverage. If you want to explore some other options you can check out this comparison by Atlassian of code coverage tools (warning: may be biased, they sell one of the options: Clover). I’ve chosen JaCoCo since it’s free and really quick to set up if you know how (and you will after reading this guide :)).

Maven configuration

Basically, you need to include some extra configuration in your pom.xml file and then, every time you execute the maven test phase, the JaCoCo plugin will generate the surefire reports.

First, you need to add JaCoCo dependency (check maven repository for the latest stable version):

Configure JaCoCo plugin (this is the minimal version):

Running the plugin

With this simple configuration, you already have all you need to execute test coverage, next time you execute maven with a goal that includes test  JaCoCo will generate the reports for you. For instance, if you execute:

You’ll see now:

As you can see a new file is being generated in the target directory.  This file is not really useful for a human but can be sent to Sonar for further analysis, or processed by several different tools (including IDEs) to show detailed reports. I’ll show you in the next section how to connect this jacoco.exec file with SonarQube.

Sending the report to Sonar

SonarQube has a really good integration with test code coverage. It allows you to analyze which parts of the code should be better covered, and you can correlate this with many other stats. If you want to send your report to your Sonar server the only thing you need to do is execute:

This command will try to reach Sonar at localhost if you don’t have an explicit configuration in your pom.xml file. If you want to connect with a different host you can also do it from the command line. For example, this command sends the JaCoCo output to a Sonar Docker image:

 

Get now the Practical Book about Microservices and start learning from zero to expert, from Monolith-first to AMQP, Routing and Service Discovery.

This is how your command output will look like. One of the Sonar sensors will detect JaCoCo output and will process it:

That’s all. Now you can go to the Sonar Web interface and check your code coverage. You will see not covered pieces of code with messages like the one below: ‘Not covered by Unit Tests‘.

If you want to see this configuration in practice you can also check my GitHub account.

Check also my Complete Guide to REST (Controller) Tests in Spring Boot: Unit and Integration Tests

sonar coverage

Related Posts

@RestController example with Spring Boot and Swagg... In this article I'll explain how to set up a basic @RestController  in a Spring Boot application, using both @GetMapping and @PostMapping annotations....
A practical book about Microservices Microservices are getting very popular these days. This type of software architecture has a lot of advantages like flexibility and ease at scale. Mapp...

9 Comments

  1. Really nice tutorial!!!

    Easy to understand with straightforward explanations.

    I liked the trick of running a docker image for Sonar server.

    Kudos to Moi

  2. Neat! It’s cool to have this way of checking your code quality even if you don’t have a full CI system in place.
    One question, are you using GitHub to host your code? In that case, perhaps you should consider using of the GitHub available integrations (such as Travis CI, Coveralis).

    They support the Jacoco plugin as well (not so sure about Sonar, that’s yet another task in my TODO stack).

    Finally, regarding testing in Spring Boot I think that Unit Testing lost a bit of usefulness against integration tests.
    Currently, there is a lot of “magic” in Spring Boot (JPA repositories, rest interfaces) so the rest of the code is pretty much POJOs and interfaces (that don’t give you much with Unit Tests).

    I’m currently exploring things like this http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/test/web/client/MockRestServiceServer.html
    which greatly eases the Integration Tests without the need of having “live” servers to interact with.

    Cheers,
    Victor

    • Thanks Víctor! Really cool stuff the MockRestServiceServer. Completely agree, coverage should focus in really important things, not just passing through all the code including simple POJOs.
      I had configured Travis in my GitHub repo (really useful), but never heard about Coveralis. Will have a look since I was looking for a cloud version of Sonar without success.
      Cheers!

  3. Hi, I’m new to SomarQube and I really struggle to make it work. I cloned your project from Github and I tried to run it with my local SonarQube 5.6.5. And I always have the following error:

    [ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.2:sonar (default-cli) on project code-quality-game: Unable to load component class org.sonar.java.SonarComponents: org/springsource/loaded/ri/ReflectiveInterceptor: org.springsource.loaded.ri.ReflectiveInterceptor -> [Help 1]

    Do you have any idea why?

    Thanks
    Ben

    • Hi jason, which problem do you mean? Didn’t experience any issue with maven so far.

Leave a Reply