Coverage testing is one of the more maligned techniques out there. It's one of my go-to tools. Once I have a test suite I think is robust, I'll go through the c

Coverage testing is one of the more maligned techniques out there. It's one of my go-to tools. Once I have a test suite I think is robust, I'll go through the code again with a coverage tool, which will usually identify error paths I didn't exercise and keep me honest. For examples, a code refactor might have introduced new error cases which weren't needed in the old code, and some code - like cleanup handling around ^C handling - is not worth fully automating; code coverage will help spot where manual tests are needed. But I really wanted to comment about one of the comments described in this essay: > One respondent seemed to conclude that the team who had 95% coverage [vs. 45%] clearly didn’t understand TDD and therefore they’d look in that program for defects. The original TDD proponents were very enthusiastic that TDD would lead to high coverage. For example, Beck wrote "TDD followed religiously should result in 100% statement coverage." I think it's safe to say that Beck understands TDD.