Using dotCover to Cover Applications, with or without ReSharperApril 20th, 2011 by Hadi Hariri
One of the main benefits of Code Coverage is that it allows us to detect certain areas, branches or lines of code that are not covered during a test run, which could lead to potential issues in production. We often write some code to find to our surprise that certain parts are never actually executed.
dotCover’s integration with ReSharper’s test runners, allows us to easily monitor what parts of our code are covered with tests. What happens though if we do not have tests? Whether we like it or not, there is a reality out there, and it’s mostly composed of legacy applications that have little to no knowledge of what a test is, let alone a unit test.
Although the ideal solution is to gradually add tests to existing code until we build up a good percentage of coverage, this is a process that takes time and is not accomplished overnight.
Covering Execution Paths
What dotCover allows us to do, independently of whether we have tests or not, is to execute an application and run an analysis report on what code paths of the application have actually been hit during the run. This often helps us track down not only potential issues (“I really thought that code was being executed”) but also resolve bugs (“Ah. So that’s why it’s not working”). Running Coverage of applications is a very simple process and does not even require ReSharper to be installed.
dotCover allows us to cover either an application that is currently open in a Visual Studio Project and selected as the Startup Application
or alternatively launch a non-executing Application:
And as we can see, it covers a wide variety of application types.
Covering an MVC Application
The example below outlines an execution path of the MVC Music Store application. We open the project and select Cover Startup Application from the dotCover menu. This immediately launches the application allowing us to execute a certain scenario. In our case, we will select some items and drop them in the cart.
When starting coverage, dotCover also launches the Controller Panel, which allows us to grab a snapshot of the execution at any point we are happy with it.
On clicking on Get Snapshot, the execution ends and we are returned to Visual Studio, were dotCover analyses the results and displays the Coverage Results Browser window
From here on, the possibilities of what we can do with these results are pretty much inline with that of running Code Coverage on our tests. We can examine coverage of projects, namespaces, classes and members. Navigate to a specific member as well as see in-place code coverage in the editor:
New to dotCover 1.1 is the ability to export results to different formats, including XML, HTML, JSON and XML for NDepend. To export to HTML for instance, we select the Export icon from the Coverage Browser Window
and select a destination to save the output too.
Although the more common usage of dotCover and in general all coverage tools are examining coverage of our code by tests, it is also useful at time to be able to run coverage of an application during a specific scenario, for testing or diagnosis reasons. Whether or not we have ReSharper, dotCover allows us to do that easily. Also remember that dotCover ships with a Console application which does permit you to run coverage of your Unit Tests from the command line and open up the results in Visual Studio.