views:

108

answers:

2

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.

+2  A: 

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.

mgroves
I think I misunderstood the question, but got voted up anyway :)
mgroves
I guess the view is that the validity of your point is so high that it outweighs its tangentiality. ;)
Cheeso
Well, since I'm getting voted up anyway, let me also state that eating a healthy breakfast is the start of a great day...a great day of high code coverage.
mgroves
+4  A: 

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.

Jared Oberhaus