Adding Jacoco code coverage measurement to a Kotlin Gradle project (and then adding coverage reports on a Jenkins pipeline)

Add code coverage to a gradle project

In order to have code coverage measurement enabled on your gradle project, you have to just add the jacocoplugin to the build.gradle “plugin” section:

adding “jacoco” plugin to Gradle “build.file”

When you now run ./gradlew test or other test tasks, you’ll see that the build folder now contains a jacoco folder, with a *.exec type of file (e.g. test.exec).

This *.execfile contains a binary code coverage report of the test run.
Nothing you can really read by yourself :-D

Fear not, for gradle is with you, giving you a couple of shiny new tasks:

• jacocoTestReport: the most important task! It generates a code coverage report (based on the last test run) in various formats (default is html)
• jacocoTestCoverageVerification: it verifies code coverage metrics based on specified rules for the test task.

So, if you now run ./gradlew jacocoTestReport, a new folder will appear under build:

This reports/jacoco is where the html reports will be generated.

You can add more customizations to jacoco setup (e.g. have reports in other formats, like csv or xml, or generating reports in a different folder): see https://docs.gradle.org/current/userguide/jacoco_plugin.html to find all the details.

Publish code coverage reports in a Jenkins pipeline

This is where things start to become more fuzzy: the available documentation is really not that clear, and all the examples on Internet (e.g. stackoverflow) may be quite outdated.
Anyway, to have the code coverage report published in your Jenkins job, just add somewhere, inside a step, the jacoco() directive (no need to install special Jenkins plugins!).

The jacoco()directive has many sensitive defaults: chances are that those defaults will be fine for you (especially if the project is a classic Maven+Java project), but in case you have to tweak a bit the jacoco()command, see the JaCoCo plugin Jenkins doc page to have all the options.

To give you a practical example, this is the jacoco directive of my Kotlin declarative pipeline:

• classPattern selects just the kotlin application classes (no need to have code coverage on my tests :-D )
• sourcePattern selects the location of the source files (again, just application files, no tests)
• sourceInclusionPattern is needed because the default (at least on my version of the jacoco Jenkins plugin) would select only Java files

I put this jacococommand in the last post section of my declarative pipeline, where the artifacts are published and the build status notifications are sent. Other people prefer to put it just after the test execution… find the best thing for you and go for it.
A good place to make up your mind is this post.

Again, to make a practical example:

That’s it!