I have spent most of this week working on integrating Clover into our environment and ripping out Cobertura. I ran into a couple of issues along the way, but we are up and running now. First one thing I dislike about Clover is by default they will mess with the maven artifacts that you may intend to ship. I think this is actually a poor way to instruct people to configure it out of the box because you are basically saying you only run it every so often on different builds or you end up having to invoke maven multiple times or other associated hacks. I didn’t like any of those options as the idea is to fail the build if coverage drops below the acceptable level and not accept the commit until that is addressed. Luckily I stumbled upon the clover2:instrument option that you can use instead of the default recommended clover2:setup goal. But then I hit a second problem, the way it names the instrumented classes with the clover2:instrument option seemed to be clashing with the JPA 2.0 Metamodel generator that we were using. I had sort of been looking for an excuse to rip that whole thing out of the project for a while and now I finally had that so I removed it from our software and replaced it with just reflection on the classes and used unit tests to verify at test time that the code wasn’t broken instead of the compile time checks we would get with the metamodel. With that gone clover integrated greatly and I got it wired into our Jenkins configuration. Today I was able to get our configuration manager to install the clover plugin into Jenkins instead of using the publish html report option and we have much nicer integration. With the Sonar Clover plugin we now have integration with Sonarqube. The Sonar plugin brings in the coverage but it no longer lists technical debt like the Cobertura does. So aside from that I think this is going to be a much better solution for us going forward and was glad we could finally switch.

Good news this week. Our purchase of Clover was approved and we will have our license keys in a matter of days. As of tomorrow it is going into our build and Cobertura is getting ripped out. You may recall I previously wrote about my issues with Cobertura. One problem was the latest version at the time 2.0.3 didn’t work with Powermock, even though 1.9.4.1 did. And the second issue I was having with it was the lack of Java 8 support since we are close to upgrading on our project at work. Well oddly enough early in this week I saw Cobertura had a new maven plug and a new release 2.1.1. I immediately updated to the 2.7 plugin to give it a go and it promptly failed on Powermock like 2.0.3. So I didn’t feel bad at all when 2 days later I found out our Clover purchase request had been approved.

In my current position one of the metrics we track is code coverage for our unit tests. When I started at the company we were using JUnit with Mockito and JaCoCo. This was a pretty good setup we got good coverage reports and Mockito makes the testing writing much easier.

One of the limitations of Mockito is that you can’t mock private methods or static methods. This presented an issue for us in reaching our desired level of coverage. We initially worked around some of the private method issues using reflection, but it wasn’t always ideal. The decision was made to use PowerMock. PowerMock solved all of our Mockito issues immediately. It was compatible with Mockito but gave us some new powerful features to allow us to get much better unit test coverage. Then we ran our Jacoco reports and found that the reporting no longer worked. Due to the way PowerMock uses byte code manipulation in order to mock static methods it is not compatible with JaCoCo and there is no plan for them to support measuring that.