Our PSI goal is to raise the code coverage with X% to at least Y% for maximum Z days at the price of Q story points!
Clap-clap-clap! Now back to work! Complicated mathematical questions like how much makes to rise 10% with 10% should be discussed elsewhere.
I’m getting more and more addicted to TDD and indeed – the code coverage is a great metrics if you apply it to code which is testable. It has some drawbacks of course:
- there might be tests which do not test anything special but rise code coverage dramatically (usually you can find these to test untestable code );
- the code coverage results in the Java technology stack are not always 100% precise due to some technical reasons;
This doesn’t make it less great though. We measure the code coverage by using the JaCoCo (java code coverage) plugin within our build tools. JaCoCo uses the JVM Tool Interface to generate its reports. The details in a nutshell may be found here. Don’t click!
As a developer I find the eclipse EclEmma plugin very useful. EclEmma helps me to spot immediately untested areas in my code (although for new code there should be few ). You can easily integrate it in IStudio by following the steps on the site of the plugin. There is just one caveat – you have to allow it for your perspective. This is not easily visible in the installation instructions.
To do that navigate to:
Windows -> Perspective -> Customize perspective
Action Set Availability. Tick
Java Code Coverage.
Now you can run it. It is really very easy. On the next screenshot there is method under test. It is immediately clear that there is no unit test that covers the event in which the user didn’t enter the
Client ID value in the configuration of our service.
If you are lazy to install EclEmma (you have no reasons to be) we even have gradle task for it. See for yourself!
gradlew tasks ... Report tasks ------------ jacocoReport - Executes all component tests, collects jacoco exxec files and generates a jacoco report for the complete component set.
What about testing pipelines? Well, I think that pipelines are not testable so I avoid using them as much as possible.