2 ms·

> And I don't believe for a minute the claims of TDD supporters that TDD naturally leads to 100% coverage. I agree with you, but at the risk of No True Scotsma

by pc86 5y ago

> And I don't believe for a minute the claims of TDD supporters that TDD naturally leads to 100% coverage. I agree with you, but at the risk of No True Scotsman'ing this, one of the TDD tenets I'm familiar with is that you write the least amount of code necessary to pass a test. So if you do it The Right Way, then you should be at 100% or something very very close to that.

eesmith 5y ago
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".

by pc86 5y ago

eesmith 5y ago

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".