Tag Archives: junit

Measuring JUnit CodeCoverage with Jacoco

Once you start working with unit tests, and that you understand how to use and write them, it’s impossible to go back. They help you decouple code, gain confidence in the behaviour you’re implementing, makes you faster by avoiding to start, and restart, a whole application.

Yet, one thing I never used up to now was code coverage. I just never took the time to dig the topic, even though that’s clearly useful. It helps maintain a team effort to ensure all new code is tested, and it gives you an idea of the risk you’re taking when chaging a line of code. Because the number of tests doesn’t give you any idea about the coverage, they may be focused on one part of the application only, or at the opposite cover a little bit every part, but not completely.

It appeared that adding code coverage measurement to a maven Java project using JUnit was as simple as adding the JaCoCo plugin to the POM file. As usual, Baeldung is your reference, but in brief :


The JaCoCo plugin will output a jacoco.exec binary file, which can be consumed by some third party tools, like SonarQube. However, you can generate a more human friendly report using the repot goal :

mvn clean jacoco:prepare-agent install jacoco:report

You’ll then have a target\site\jacoco\index.html report detailing your code coverage :

Fixing Mockito UnnecessaryStubbingException with JUnit5

After upgrading to JUnit 5, you may bump into some unit tests now failing with the following error :

Unnecessary stubbings detected.
Clean & maintainable test code requires zero unnecessary code.
Following stubbings are unnecessary (click to navigate to relevant line of code):...

JUnit 5 is tricter regarding stubbing. As explained in the error message, unnecessary stubbing is not a good practice. It usually results from copy and paste, and creates confusion about the tested behaviour. In such a situation, you just want to remove the unnecessary stubbing.

However, there are some cases when you’d like a less strict approach. For example, when you use a helper method that does some mocking that is required by most of the cases, but not all. Than you have to choices :

  • instead of mocking directly with “when(…).then(…)”, prefix the call with lenient(). Ex
  • else, annotate your test class with :
    @MockitoSettings(strictness = Strictness.LENIENT)
    It will relax the mockito stubbing rules.