Alex Ruiz's Blog

I’ve been using Clover for some time in FEST and I have found very useful. I don’t believe in “x”% coverage as a sign of good-quality code. Instead, I use code coverage to decide which parts of my code need more testing.

Something I’m not comfortable with is seeing 0% coverage in private constructors. IMHO, Clover should ignore those by default because, in most cases, nobody calls those constructors. Clover provides the source code directives “CLOVER:OFF” and “CLOVER:ON” to turn code coverage off an on. I particularly don’t like using those directives because they add noise to our code and they are not DRY (we need to add them to every single Java class that, in my case, has private constructors.)

Clover provides a feature called “coverage context” that can be used together with “context filters” to specify the portions of code that should be excluded from the coverage report. The main benefit is that we only need to configure Clover once, without any changes in source code. In my case, I’m using a “method context” to match private constructors, with this regular expression:

(.* )?private +[a-zA-Z0-9_$]+ *\( *\).*

The following is a sample configuration in Maven:

1
2
3
4
5
6
7
8
9
10

<plugin>
  <groupId>com.atlassian.maven.plugins</groupId>
  <artifactId>maven-clover2-plugin</artifactId>
  <configuration>
    <methodContexts>
      <private-constructor>(.* )?private +[a-zA-Z0-9_$]+ *\( *\).*</private-constructor>
    </methodContexts>
    <contextFilters>private-constructor</contextFilters>
  </configuration>
</plugin>

On lines 5 to 7 we define the method context, under the name “private-constructor,” that matches all private constructors in our Java classes. On line 8 we instruct Clover to exclude from the coverage report the methods that match the context “private-constructor.”

Enjoy!