This post originated from an RSS feed registered with .NET Buzz
by Tim Sneath.
Original Post: Free .NET Code Coverage Tool
Feed Title: Tim Sneath's Blog
Feed URL: /msdnerror.htm?aspxerrorpath=/tims/Rss.aspx
Feed Description: Random mumblings on Microsoft, .NET, and other topics.
I'm not a heavy Visual FoxPro user - although it is installed on my development machine - but I've often admired some of its capabilities. Although it doesn't mesh desperately closely with the general .NET architecture, it is a relatively powerful database development environment that can count some of the most loyal and vocal customers that I've ever encountered. It also boasts a powerful set of debugger tools, some of which aren't available in any of our other developer tools.
One such tool is support for logging of code coverage information, an area that's often overlooked in the software testing that many of us conduct on our applications. Code coverage gives you information on which lines of code have been executed and how long it took to execute them. It's of great benefit in larger code bases, since it's often difficult to be sure that every line of code (including all exception cases) have been properly exercised. Without code coverage, it's quite easy to ship an application containing large chunks that have never been run - a recipe for bugs and application failure. Some code coverage tools also offer profiling capabilities to establish which code is executed the most regularly: these routines are of course fertile ground for performance tuning.
We use code coverage extensively for many of our products - special code coverage builds are available during the development process that incorporate logging of this information for further analysis. But there's no built-in support in Visual Studio .NET for this feature, which is a pity.
To the rescue comes Stuart Richardson, one of my colleagues in the UK Solutions Development Centre, who's put together a tool that performs code coverage on .NET assemblies written in any language (it operates at the IL level). You can automate the tool via batch files, or as part of the build process using the new MSBuild engine that will ship in Whidbey. If you've got symbols and source available, the tool offers code colouring so you can see what has been executed.
In summary, it's well worth grabbing this tool from GotDotNet and using it as part of your own development / testing process - you may be surprised at what you find!
Previous Topic
