Yes, you might start that way. Then over time you lose it, unless you are actively doing coverage testing. Here's the clearest example. For a while I had a cod

Yes, you might start that way. Then over time you lose it, unless you are actively doing coverage testing. Here's the clearest example. For a while I had a code base which supported both Python 2 and Python 3. I dropped Python 2 support and removed the compatibility layer. I'm still finding places where I have Python 2 code paths. (Clearly I'm not using enough coverage testing.) Here's another example. Suppose I have a single public entry point, which internally calls a number of private units. I've carefully tested only at that public entry point so my test coupling isn't an issue. I then realize that I can special case (say) n=0 early in the public entry point. Now, a number of the private units no longer need to handle the n=0 case. Manual inspection during refactoring might catch all of those code paths which are no longer used. I know I'm not diligent enough to find all those cases. I've even had times where I find an entire function is no longer being called at all, because a refactoring removed the need to have it. Once you've had a few refactorings of a non-trivial code base, even during its greenfield development phase, you're almost certainly going to have dead code. Even when using TDD. No, I don't know what the coverage rate would be on a TDD project which doesn't use code coverage. But my experience tells me not to believe Kent Beck's statement "TDD followed religiously should result in 100% statement coverage".