Why would I *not* collect code-coverage data in unit tests, in VS2008?

Question

If I'm running a suite of tests, is there a reason I would NOT want to collect code coverage data for the tests?

What's the expected cost, in terms of runtime, storage, or anything else? I'm trying to decide if I would ever want to run with code coverage data collection OFF.

Answer 1

The reason not to do this in unit tests is so that unit tests can execute quickly, so you don't have an excuse to not execute your unit tests.

Given your question, it sounds like you're not bothered by any delay caused by gathering this information; my recommendation is to keep it like it is, and when the delay becomes a "bother", then spend some time creating a "quick" build and a "coverage" build.

Answer 2

I wouldn't use code coverage as an absolute measure of anything. High code coverage is good, but 100% code coverage isn't necessarily better, and could be worse in terms of time spent trying to cover that last bit.

As part of a larger package of metrics, though, code coverage is great.