Why would I *not* collect code-coverage data in unit tests, in VS2008?
.net, c#, code-coverage, unit-testing, visual-studio-2008
Solution
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.
Problem
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.