After bashing code coverage metrics I came across an article from Naresh Jain about being seduced by code coverage numbers and gaming the system:
I once worked for a manager (a.k.a Scrum Master) who insisted that we should have at least 85% code coverage on our project. If we did not meet the targeted coverage numbers this sprint, then the whole team would face the consequences during the upcoming performance appraisals. In spite of trying to talk to her, she insisted. I would like to believe that the manager had good intent and was trying to encourage developers to write clean, tested code.
My thoughts on code coverage have been expressed before, but Kevin Rutkowski does a good job so I’ll use his words:
The bottom line is that tests can easily be written that exercise code without actually testing anything. So, when a team sets a specific goal of 100% Code Coverage and has a tight deadline, it is likely that a large number of those tests will be low quality.