NCover 4: Plugged In

We’ve put a lot of work into designing NCover plugins for Microsoft Visual Studio. We saw that our customers really wanted it (including me), and it was obvious to us that Visual Studio was a key integration point that would benefit a huge number of our customers, so we made it a priority.

After several iterations of a plugin for VS2008 (and later 2010) using the code coverage paradigm offered in NCover 2 and 3, we decided not to put it out in the wild quite yet. There are certain principles and goals that we had when designing a plugin for Visual Studio, centered around the developer:

• Primarily write code in visual studio.
• Don’t always want plugins to be in their way.
• Would love NCover to “figure it out” and show coverage with minimal configuration effort.

We tried several different ways of presenting coverage metrics, but none of them seemed simple and “out of the way” enough. Then the whole concept of coverage files, project files, etc. seemed to muddy the waters even more, taking us further from our commitment to IFB – (Imagination, Function, and Beauty). Something had to give.

Then came NCover 4.

We started challenging the code coverage paradigm used in NCover 3, and came up with a few key ideas that would make NCover a simpler, more effective product:

• The whole concept of NCover being a program that runs other programs limited its flexibility in different environments. NCover needed to become an “all seeing eye,” a service that knows about all running processes and looks to a central location to determine whether or not to collect coverage data.
• Coverage data needs to be in one place. Users don’t need to worry about opening files.
• It was time to take a fresh look at how we display coverage data. There is something ugly about just putting numbers next to nodes in a tree view.

Redesigning NCover from the ground up using these goals allowed us to design with the goal of easy integration into other places like visual studio. Instead of just making a plugin that opens coverage files, we were able to achieve a deeper level of integration. Here is how NCover’s redesign made Visual Studio integration so natural:

• HTML5 – Since NCover is now a server, why not embed a web server and write the GUI with HTML? Then figure out how to embed a browser into Visual Studio and voilà! Easy, consistent integration. The pages you see in the web app are the same pages that show up in all Visual Studio plugins.

• Modular panels – Writing the GUI with HTML allowed us to easily split the panels up for display in different windows within Visual Studio. This allows the developer to hide panels he doesn’t wish to see – (Explorer view, Source view, Statistics view, Settings window). Out of the developer’s way? Check.
• All data is in one place – This means that NCover does not have to tie solutions or projects to NCover projects. The plugin can look up the latest coverage data for a particular document, class, method, etc, across projects. This solves part of our goal for NCover to “just figure it out.”

• NCover sees all – No more worrying about running your program as a subprocess of NCover. Just run it however you normally would–command line, test runner plugin, gui–whatever! NCover sees it. This also made it easy to implement the auto detect feature included in NCover 4, which is the same web panel used in the plugins. You can be 3 clicks away from having a new project waiting for your process to run–all from within Visual Studio!

Clearly the changes made in NCover 4 played a crucial role in the success of the design of the NCover plugins for Visual Studio 2008 and 2010. It’s coming sooner than you think, so get ready… I’m sure you’ll love it!