vBloga collection of my notes and thoughts…

Code coverage is a very important metric in a continuous deployment process, to ensure there is sufficient test coverage in place. NCover and JetBrains dotCover are two popular .NET code coverage tools.

NCover has been around longer than dotCover. This is evident in the amount of features that NCover has. NCover has better support for scripting. Data collection, manipulation, analysis, and reporting can all be driven through a command line interface. It records trends, is capable of profiling Windows services, and can produce various reports in HTML format, which are some of our primary requirements.

dotCover’s strong point is its Visual Studio integration. It is easier to setup compared to NCover. It can show the lines of code covered directly in the Visual Studio IDE; whereas NCover presents this information in its own GUI.

We currently employ both these tools in our continuous deployment environment. The automated Jenkins build uses NCover to produce a HTML code coverage report of our entire test suite, which we then publish onto a web server, where it is accessible to all developers. Running NCover on the build machine significantly cuts down the licensing costs. As there is currently a huge project underway that sees a lot of new tests being developed, developers can benefit greatly from the rapid feedback that dotCover provides. Several developers who are actively developing tests have dotCover on their machines. For the long term, we envisage NCover alone should be sufficient.

As the Jenkins builds take longer to run, we found that multiple builds are ending up on the build queue. As we are only interested in the very latest build, the older build requests are effectively obsolete. By using the Groovy plugin, we were able to write a script to cancel the old build requests. We added an Execute system Groovy script build step with the following command:

println("Analysing Jenkins queue...");
jobName = Thread.currentThread().executable.toString().split()[0];
for (item in hudson.model.Hudson.instance.getQueue().getItems()) {
  if (jobName.equals(item.task.getName())) {
    println("Aborting current build due to a more recent build request.");
    hudson.model.Executor.currentExecutor().interrupt();
    break;
  }
}

The script basically searches the build queue for any build requests that have the same name as itself. If any are found, the script terminates the current build. The current build status will then show as aborted.