I wanted to get code coverage for my current groovy project. Since I use gradle and all of my source is written in groovy, I searched for a gradle plugin that provides cobertura functionality for groovy files. I found two (perhaps there are a more available)
Using both plugins wasn’t a big deal. There is a slight difference how to set them up in your build.gradle file though. Both plugins provide very similar configuration options to tweak cobertura’s behavior. Let’s take a look.
Adding the plugin to the build.gradle
I’m using gradle 1.4 for this exercise and I added the following to my build.gradle:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath "net.saliman:gradle-cobertura-plugin:1.1.0"
}
}
apply plugin: 'cobertura
This will provide you with four new tasks:
coberturaInstrumentMaincoberturaInstrumentTesttestCoberturaReportcoberturaConfigureTest
So, which task to call to determine the code coverage? Simply run the test tasks and your source will be instrumented prior to executing your tests.
But what you really want, is to run the check tasks because this will not only run your tests on your previously instrumented source, but it will also create the coverage report. And that’s basically what we want.
The plugin provides some configuration options to tweak cobertura’s behavior
| option |
description |
| format |
’html’ (default) or ’xml’ |
| reportsDir |
Path to report directory for coverage report. Defaults to ${project.reportsDir.path}/cobertura |
| includes |
List glob paths to be reported on. Defaults to [‘**/*.java', ‘**/*.groovy', ‘**/*.scala’] |
| excludes |
List glob paths to exclude from reporting. Defaults to [‘**/*Test.java', '**/*Test.groovy', '**/*Test.scala’] |
| ignores |
List regexes of classes to exclude from instrumentation. Defaults to [‘org.apache.tools.*', 'net.sourceforge.cobertura.*’] |
To specify the output format of cobertura’s coverage report you have to do this:
cobertura {
format = ‘xml’
}
This plugin is based on the work of gradle_cobertura. The original version had some issue with the latest gradle version, so I decided to pick one of the 20 forks. The one with the most recent changes was Steve Saliman’s Cobertura plugin. You can find the setup instructions in the README. Currently the compatibility chart shows that gradle 1.1 is the highest supported version right now. I’m using it with gradle 1.2, 1.3 and 1.4 and they work too. So, let’s move ahead and give it a try.
Adding the plugin to the build.gradle
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath "net.saliman:gradle-cobertura-plugin:1.1.1"
}
}
apply plugin: 'cobertura'
This will add 2 new tasks:
To get your coverage report you need to run the cobertura task and the report will be created.
There are a couple of options available to this plugin to change the cobertura behavior:
| option |
description |
| coverageDirs |
Directories under the base directory containing classes to be instrumented. Defaults to ${project.sourceSets.main.classesDir.path} |
| coverageDatafile |
Path to data file to use for Cobertura. Defaults to ${project.buildDir.path}/cobertura/cobertura.ser |
| coverageReportDir |
Path to report directory for coverage report. Defaults to ${project.reportsDir.path}/cobertura |
| coverageFormats |
Formats of cobertura report. Default is a single report in ‘html’ format |
| coverageSourceDirs |
Directories of source files to use. Defaults to ${project.sourceSets.main.java.srcDirs] |
| coverageIncludes |
List of include patterns |
| coverageExcludes |
List of exclude patterns |
| coverageIgnores |
List of ignore patterns |
Fix broken links in coverage report
In order to have a working link to the groovy source files in the coverage report, it’s necessary to add the following to your build.gradle. This will add the groovy source directory to the list of coverageSourceDirs
cobertura {
coverageSourceDirs << project.sourceSets.main.groovy.srcDirs
}
Report location
For both plugins, the generated report can be found in build/reports/cobertura.
Summary
I have to admit, that both plugins are too similar in functionality to declare a clear favorite. In general, both plugins have subtle differences in regards of their configuration. I like that Eric Wendelin’s Cobertura plugin supports groovy (and scala) files right out of the box without further configuration. But this is only a very small advantage. I’ll stick with Steve Saliman’s Cobertura plugin for a while, since there is still active development. Not a strong reason, but as I mentioned earlier, there are only subtle differences between both plugins.
The choice is up to you.
