Coverage testing is one of the more maligned techniques out there. It&#x27;s one of my go-to tools. Once I have a test suite I think is robust, I&#x27;ll go through the code again with a coverage tool, which will usually identify error paths I didn&#x27;t exercise and keep me honest. For examples, a code refactor might have introduced new error cases which weren&#x27;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.<p>But I really wanted to comment about one of the comments described in this essay:<p>&gt; 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.<p>The original TDD proponents were very enthusiastic that TDD would lead to high coverage. For example, Beck wrote &quot;TDD followed religiously should result in 100% statement coverage.&quot; I think it&#x27;s safe to say that Beck understands TDD.