dotCover - A New Kid on the (development) Block

CodeProject

These days, JetBrains (the manufacturer of ReSharper (R#)) released the beta version of a new code coverage tool – dotCover. Because I’m a big fan of the R# add-in, I was particularly curious about having a first look at the newest JetBrains child. Notably, I wanted to see how it would take advantage of its deep R#/VS integration to make code coverage an integral part of a developer’s working experience. Here are my first impressions about it…

Note: Because I’m using NCover for Code coverage analysis at the moment, I cannot help comparing these two tools, although this might not be totally appropriate: dotCover is designed to deeply integrate with R# and Visual Studio, whereas NCover is a stand-alone application. Also, NCover is a mature and feature-rich application, whereas dotCover is in its early infancy…

Some useful related resources (links to website, documentation material and some videos) can be found in my toolbox on Delicious:

• dotCover - http://delicious.com/thomasweller/toolbox+dotcover
• NCover - http://delicious.com/thomasweller/toolbox+ncover
• or both - http://delicious.com/thomasweller/toolbox+code-coverage

About Code Coverage

Much has been written about Code Coverage and about what it can do and what not – see for example here and here. The bottom line is: The single useful aspect of Code Coverage is that it shows you which parts of your production code are NOT covered by any tests, and thus gives you a basis to decide upon those areas: You simply may have overlooked it, or you may have made the explicit decision to not test it.

And this is exactly what I’m interested in when writing tests - be it after the fact (i.e., covering a pre-existing codebase with tests) or be it when authoring new code in a TDD process: I want to quickly see which parts of the production code are covered with tests, and I want to be able to quickly jump to and inspect code which is not. In short: It’s productivity what I’m looking for in the first place. In-depth information - like it is provided by NCover - is part of a broader picture that becomes important when deeply analyzing an entire codebase or monitoring historical trend data. But for now, let’s exclusively focus on the coding process itself…

Running Tests with Coverage

DotCover will add a new item to the familiar R# menu, which allows you to run tests with coverage just like you would run ‘normal’ tests from R#:

DotCover also adds a new tab to the R# Unit Test Sessions tool window, showing the results of the current coverage run:

 From there, you can directly navigate to the code under test via double click, which will be highlighted in red and green according to the measured test coverage:

Navigating from Production Code to Test Code

It is also possible to browse your test code <-> production code connections from the other direction. After a coverage run, dotCover will show you which tests are operating on a selected code line when right-clicking it and choosing Show Covering Tests form the context menu:

This will open up a popup window like the one below, giving you a list of relevant tests:

Summary

The dotCover tool makes code coverage analysis as simple and fast as it was never before. It doesn’t provide all the sophisticated features that NCover has (e.g. branch coverage or trend analysis, to name just two…), but instead it integrates deeply with your coding process and lets you browse and navigate between test code and production code inside VS with only one or two mouse clicks while highlighting the covered/uncovered code areas. Unlike NCover, there’s no need to switch between different applications and to figure out complicated sets of options and/or command lines. Especially when used with a consequent TDD process (like the one I described here in some detail), dotCover is a great help in writing tests and can strongly boost a developer’s productivity.

That’s the pro side of the coin. The contra for now is, that there is not yet any automation support – meaning that it’s not yet possible to use dotCover coverage reports from a Continuous Integration process. This is where NCover is quite ahead at the moment: It allows you to generate nice and detailed coverage reports and data from the command line or via MSBuild/NAnt tasks and thus can seamlessly be integrated with a CI tool like e.g. CruiseControl.NET.

Conclusion

DotCover does a great job on the development side of things, because it integrates perfectly with R# and VS. From a developer’s point of view, code coverage never was easier. This part of the picture is really impressing IMHO. (And as a side note: Although the current version is in a quite early beta state, I found it to be impressingly stable…)

However, there is not yet any automation support (a command-line interface and probably some MSBuild and NAnt tasks), so dotCover cannot be integrated with any Continuous Integration tool at the moment, which (at least for me) means that it’s not yet ready for production regarding the current feature set. But as said before, dotCover is in an early beta, and these features are announced for the final 1.0 version. Like the JetBrains people put it:

dotCover is still in its infancy and we’ve got a lot planned in terms of features and functionality. Quite a few people have asked whether it will support running coverage reports from a console, which is important for continuous integration. dotCover will support running from a console with some basic functionality, and we have plans to include specific features for CI processes.

So let’s just look forward to the things to come…