I have noticed that the act of measuring code coverage is pretty much standard (even outside of MS this is becoming true). If you are measuring code coverage, what are you trying to determine?
Really – I want to know. Please answer.
Since you haven’t answered, let me rephrase: If you, for example, have a code coverage goal of 80% block coverage, what does that metric tell you?
Write your answer here: ________________________________
Fine. You don’t have to answer if you don’t want to.
I’ve found that most teams use code coverage as a measure of test effectiveness or test thoroughness.
Code coverage only tells you what you haven’t tested. You have 80% code coverage? Great – that means that only 20% of your code is completely untested – woo hoo! It should also be obvious that 100% code coverage certainly doesn’t mean you’re bug free (or anywhere close to it).
I’m not saying that high levels of code coverage are a bad thing. CC is a great tool for risk assessment, but that’s where the focus needs to be. Rather than driving toward a goal of 80% code coverage, I think you should drive toward a goal of “No more than 20% completely untested code”. It’s really the same metric, but I think the behaviors to reach that goal may be different if people thought about it in a different way.