NCover 5 and Catching up

I previously wrote about code coverage for automated tests using NCover 1, and then about updating to NCover 3. Now, some years and two major versions later, it’s time to revisit the tool.

I recommend reading the previous two posts for background on code coverage and NCover. Details have changed – hence this post – but the basis remains the same.

I used NCover 4, but for some reason skipped doing a review. This post will catch up with changes introduced in v4, and then move on to v5.

Disclosure: I was invited by NCover to write a review of v5 in exchange for a complimentary license. Take that for what you will.

NCover Changes

NCover changed their application model with version 4. Instead of the application that was used in v3, NCover 4 came in three pieces: Bolt, Desktop, and Central.

Bolt is an extension for Visual Studio, and can be used to run unit tests. It does not itself generate coverage data. Bolt can be installed standalone, or while installing Desktop.

Desktop is the closest to the way NCover was in v3, and is the topic of this overview. It is implemented as a Windows service, with the viewer running in a web browser. When a project is configured in NCover Desktop, the tool watches the project for running tests and generates coverage data.

Code Central is also a web-based viewer, but it aggregates coverage data from individual Desktop installations or a related tool called Collector. Central can then be used to fully analyze the coverage data and generate reports.

Desktop and Bolt are both user-level tools. Central is a team-level tool.

I was at first apprehensive of this new model, having become accustomed to the version 3 interface. Being human, I didn’t like change. To his credit, Bryn, an NCover representative, exchanged some emails with me and shared some resources and feedback from other users favouring the new approach. It took me a while, but I became accustomed to the new NCover.

An advantage to the new approach is centralization – all projects with automated tests can be configured in one interface for tracking coverage data.

Installing Desktop is straightforward – just download and run from the NCover website.

NCover desktop installer
NCover desktop installer

There are options for integration with multiple versions of Visual Studio – that will be for Bolt – in addition to the core application. Once the process is done, Desktop can be run.

NCover desktop start view
NCover desktop start view

Each time Desktop is run, the user is greeted with a welcoming screen. Once that is dismissed, the fun begins.

NCover desktop top bar
NCover desktop top bar

On a fresh install, the Desktop view is pretty spare – the only visible feature is the horizontal bar across the top of the viewport (pictured above). Clicking the NCover logo at the left end will show a menu, Windows-style, shown below.

NCover desktop menu
NCover desktop menu

There isn’t a lot there, but for convenient access to some resources.

A code coverage project can be configured by clicking Add New near the right end of the menu bar. The resulting dialog is pictured below.

NCover create project - processes
NCover create project – processes

The first task is to enter a name for the project in the top textbox. Setting up NCover to watch certain processes is easy – just hit the Auto-Configure button, which changes the dialog.

NCover create project - detecting processes
NCover create project – detecting processes

As with version 3, NCover doesn’t watch for tests running, but watches processes running the tests. There are numerous test runners available, including but not limited to the runner in ReSharper, TestDriven.net, and NCover Bolt. Clicking the aforementioned button will also start the detection process, which watches for processes running tests. Simply run the tool of choice, and it should appear in the dialog. My result, using Resharper, is shown below.

NCover create project - detected processes
NCover create project – detected processes

It’s not useful to generate coverage data for tools related to the testing process. At this stage, it is prudent to add some filters to ensure that only the code of interest gets covered. By default, all running code is included in coverage data. By switching the Pre-coverage filter to Create filter, this convention is reversed. Running code must be explicitly included to gain coverage data. Clicking once in the checkbox next to a module excludes it from coverage (which is the default in this mode anyway). Clicking again causes the module to be included in coverage. Clicking a third time clears the checkbox.

My revised coverage setup is reflected below:

NCover create project - detected processes, filtered
NCover create project – detected processes, filtered

There are three other tabs to be viewed. Next is Filters.

NCover create project - filters
NCover create project – filters

By default, the Filters section is empty. However, when specific inclusions are made, as I have already done, the filtered listing reflects these settings, as shown below.

NCover create project - active filters
NCover create project – active filters

The next section is very familiar coming from version 3. There was a very similar view for setting desirable thresholds for coverage levels.

NCover create project - thresholds
NCover create project – thresholds

Last but not least is a Settings section with some additional assorted options.

NCover create project - settings
NCover create project – settings

None of the above sections, aside from the first, need any modifying to get started. Clicking the Save Local button will update the top bar to show the new project.

NCover top bar with new project
NCover top bar with new project

The project displayed is a new one which I’m starting to add some tests to. Naughty me, not practicing TDD, but there it is. That explains the relative lack of results shown.

In my previous overview, I also showed how to integrate NCover into automated build processes. As with the interface changes, the integration options changed as well. As I’m currently revisiting my build automation setup, I will come back to build process integration.

That’s enough for now. I’ve given an overview of the recent release, admitted to some stubbornness against change, and revealed my lapse from TDD. I’m going to add some tests and generate some coverage data, and come back to the coverage analysis tools, as well as automation integration.

In the meantime, NCover have a presence on Facebook, Twitter, and Google+. They also blog about the product and related tools and practices.

Conclusion

Despite initial misgivings, I got to like the new model that NCover (Desktop) works under. It allows tracking coverage data from multiple projects in one location.

Bolt seems superfluous, as there are numerous test runners available. I’m happy to use the one included in ReSharper.

Code Central is expensive, and better suited for teams rather than individual developers.

Another peeve: the cost of Desktop is quite a bit higher than the version 3 that I used previously. NCover do offer discounts for renewing licenses to continue support and updates, but it’s still a bit hefty for one tool for an individual developer. I use other supporting tools (e.g. ReSharper) that cost rather less.

The Desktop interface has changed. In some ways it’s better than the application-based interface of v3. In other ways it hasn’t much changed, yet still effectively delivers the message.