Keep a code coverage on a radar

Last time we discussed significance of unit tests. They must be clean, fast and also comprehensive. First two points developer can control manually. But what about the last? Value of tests is directly proportional to the code coverage. Of course the level of code coverage is not a main purpose, but it is a good sign of their usefulness. How can we control and maintain this rate on sufficient level? Cobertura maven plugin will help us.

First of all we should realize that decreasing of code coverage is very undesirable. If this rate decrease after some commit that means someone don’t care enough about quality of his code and wrote few tests (or didn’t write any tests for new code). Such situations must be checked automatically and we will prevent that via cobertura-maven-plugin. Our purpose is fail build if code coverage became less than certain threshold.

Let’s take a look at simple configuration of this plugin. For example, consider multi-module maven project. In parent pom.xml file configuration should be like this

We have just noted that our build will be failed if line coverage is less than value set in totalLineRate.unit.tests.coverage property. Also we linked our code coverage checking to the prepare-package phase. That means plugin will fail building application process (if needed) on prepare-package phase. Note that this plugin runs tests and check code coverage for all submodules separately. That means you should set different test level for each module in totalLineRate.unit.tests.coverage property.

That’s all. Now we have a guardian which will be responsible for our code coverage level. If something goes wrong plugin will fail our build with message

What should we do if we see this message? Of course we must write more tests or improve already existing. But where is the place with low code coverage? Just execute “mvn cobertura:cobertura” and after that go to the ${project.build.directory}/site/cobertura/index.html


As you can see it’s a very useful plugin that helps us maintain quality of our code on a good level. But there is “a little” problem. Considered plugin relies on Cobertura executables and runs tests in his own lifecycle. As a result all tests must be run twice. Of course unit tests must be fast, but this fact can not be an excuse. As a solution we link cobertura goal to prepare-package phase that runs less often than test phase. Also we can use profiles and run cobertura checking only on CI server, but I really don’t advise to do that, because as earlier developer will know about the problem as faster he or she will fix it.

There are some other maven plugins that can do the same as considered in this article. For example it is Jacoco. I didn’t choose this plugin, because it doesn’t work with PowerMock. You can object that is not good idea, because using PowerMock is a sign that your code don't have a good design. But we will discuss that next time.


Comments

Popular posts from this blog

JEEConf 2017 How it was

Java 8 vs GoF: Strategy

Separate and rule your tests