Measuring code coverage is a good way to figure out if a project has a healthy codebase or not. There is no magic number for coverage, as with many things it software the right answer depends on the context; this being said some projects strive for the perfect 100% and will relentlessly pursue that goal, no matter what. There are a handful of projects in the Java space that can calculate the coveted number: Cobertura, JaCoCo, and OpenClover. Of the three I'd say JaCoCo is the one I use most for the following reasons:
- JaCoCo delivers better branch coverage statistics than Cobertura.
- The commercial nature of Clover (at the time) appears to have discouraged developers from writing integration tools. But OpenClover is a different matter; OpenClover is the open source, non-licensed version of Clover, a tool owned by Atlassian. I'm very much looking forward to future integration tools.
No matter which tool you pick code coverage will give you a snapshot in time. It would be great to keep track of coverage over time, and that's precisely one of the goals of coveralls.io. This service allows you to track coverage for a wide variety of languages and coverage tools, not just Java. Coveralls can keep track of public and private repositories hosted on GitHub and/or BitBucket. Mater of fact, you can use your same login credentials from either GitHub or BitBucket to log into this service, neat! The next screenshot shows coverage reports across time and builds for the Griffon project
It looks like Griffon's code coverage number has oscillated between 60% and 70% and at some point there was a gap of no values, gasp! The gap is explained by debug symbols being turned of when the builds were made, thus no coverage was reported at all. Once we noticed the problem, debug information was added back and the report got back on track. Here's another segment of the same page
Coming back to Java you may be wondering how your project may interact with Coveralls. First you need to make sure that your projects generates a code coverage report as part of its build; pick either JaCoCo or Cobertura. Next use the appropriate Coveralls plugin depending on your build tool: coveralls-gradle-plugin or coveralls-maven-plugin. Finally, make sure to trigger the build phase that gathers all reports and pushes them to coveralls.io during y build on CI. The aforementioned plugins have integrated support for popular CI options, such as Travis & AppVeyor, thus their usage should be fairly straight forward. Here's for example how a Gradle based single project build could look like when configured on Travis
language: java
install: true
cache:
directories:
- $HOME/.m2
- $HOME/.gradle
before_script:
- ./gradlew --version
script:
- TERM=dumb ./gradlew build jacocoTestReport jacocoRootReport
jdk:
- oraclejdk8
after_success:
./gradlew coveralls
This configuration adds an extra step at the end of the build. If successful the build will collect coverage reports and push them to coveralls.io, which may look like this
Disclaimer: I’m in no way related to Coveralls nor the company behind it. I merely provide information on this service based on its free version.
