Based on your HN account name and the linked-to domain, I believe one person is behind both, and I will use "you" to refer to that person. "I was really happy

Based on your HN account name and the linked-to domain, I believe one person is behind both, and I will use "you" to refer to that person. "I was really happy to see that my code coverage was over 95%" If you look at some of the TDD literature you'll find that some of its advocates believe (or at least believed) that it would naturally lead to 100% code coverage. For a semi-arbitrarily selected quote, from http://accu.org/index.php/journals/1325 http://accu.org/index.php/journals/1325 : > In theory, when using TDD we will always get 100 percent coverage (remember, we're only supposed to write code as an automated test fails). and in my notes I have that Kent Beck wrote "TDD followed religiously should result in 100% statement coverage." I think your own experience shows that this statement isn't true. My observation is that the refactor step implicitly allows new untested code paths. "But testable code will make your product more reliable, so you shouldn’t chose between these two, but find a balance between them" When I read your essay I wondered why you were focused on unit tests. Integration tests can also be used to check that low-level accessors work. While they don't pin down the error to the precise unit, this is also the sort of error which is easy to track down once you know that an error exists, so there isn't a strong need for a unit test over an integration test. You might be interested in James Coplien's "Why Most Unit Testing is Waste" at http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Wa... , and its followup at http://www.rbcs-us.com/documents/Segue.pdf http://www.rbcs-us.com/documents/Segue.pdf , as well as plenty of discussion about it here on HN and elsewhere.