views:

2035

answers:

4

We're getting our feet wet with unit testing in VS 2008 Professional Edition and have hit what might be a pretty large snag: there appears to be no way to determine code coverage in this particular VS edition. It seems that this is something only available in VS Team System Development Edition.

In other words, VS 2008 Professional Edition allows you to write all the unit tests you want, but provides NO WAY to check which code does not have an associated unit test (or how much code is covered by tests). Is this observation correct?

If so, can someone recommend a 3rd-party tool to determine code coverage? I tried TestMatrix but was thoroughly unimpressed (The settings screen was hiding the OK and Cancel buttons at 120 DPI, running my current set of tests caused a complete VS lockup).

A side question: Instead of a 3rd party coverage tool, and instead of upgrading to VS Team System Development Edition, would it make better sense to adopt NUnit and find a free/low-cost code coverage tool? We're not knee-deep in unit testing yet, and we want to choose a testing method which won't hamper our efforts down the line... and not break the bank.

+1  A: 

I'm using PartCover to get basic information on code coverage from my NUnit tests. While the interface is not the slickest experience under the sun, it gets the job done and is open source.

David Schmitt
I briefly tried PartCover but had trouble figuring it out. Is it intended for NUnit only (since it's a NCover clone), or can it be used with MS's testing tools in VS 2008? Thanks!
I believe you can use it to test coverage of any .exe you can start with PartCover. But I'm using it currently only for NUnit tests.
David Schmitt
+3  A: 

NCover

John Sheehan
A: 

I've been using NCover with NUnit under VS2008 for a few days. I've found it so easy to find and fill gaps in my test coverage, I've giggled aloud when NCover pops up.

One tip: if your tests are in the same file as the code they're testing, don't bother running NCover unless all of your tests pass. Otherwise, it'll flag all the failing test methods' trailing braces as uncovered. Though, perhaps that's just a hint that I should be putting my tests in a different file…

Garth T Kidd
It's a good idea to have your test's in a seperate project/assembly
Chris Canal
Whoa yeah, you don't want your tests in the same file. Why bloat your release with unit testing and testing dependencies?
Chris Marasti-Georg
I think there are some nice advantages with putting unit tests in the same file as the code they are testing. The idea shouldn't be dismissed without thought. You can still exclude them from production code, but some people ship tests with production code even. There are some advantages to that too.
Lance Fisher