5 ms·

TDD is climbing with ropes; it's useful in situations where you don't know how to get all the way to the top but want to try stuff from where you've gotten to w

TDD is climbing with ropes; it's useful in situations where you don't know how to get all the way to the top but want to try stuff from where you've gotten to without falling all the way to the bottom.

pc86 5y ago
Isn't the argument TFA is making the opposite, though? That TDD only really makes sense when you're working a very "crisply defined" specification?
- eesmith 5y ago
  Yes, that's my interpretation. This reminded me of when Ron Jeffries tried to use TDD to write a Sudoku solver, but didn't manage to do it. The take-home lesson was summarized at https://www.infoq.com/news/2007/05/tdd-sudoku/ https://www.infoq.com/news/2007/05/tdd-sudoku/ as "while TDD may not be the best tool for inventing new algorithms, it may very well be the best tool for applying those algorithms to the problem at hand." In this context, I think of "crisply defined" as being when know the algorithms, and input/output format, and want to get things working together. I still don't find TDD useful. Even in that case, I much more a spike-then-stabilize developer, with most of my tests added at the end, followed by coverage analysis to identify missing tests. (And I don't believe for a minute the claims of TDD supporters that TDD naturally leads to 100% coverage.)
  - 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".

pc86 5y ago

Isn't the argument TFA is making the opposite, though? That TDD only really makes sense when you're working a very "crisply defined" specification?

eesmith 5y ago
Yes, that's my interpretation. This reminded me of when Ron Jeffries tried to use TDD to write a Sudoku solver, but didn't manage to do it. The take-home lesson was summarized at https://www.infoq.com/news/2007/05/tdd-sudoku/ https://www.infoq.com/news/2007/05/tdd-sudoku/ as "while TDD may not be the best tool for inventing new algorithms, it may very well be the best tool for applying those algorithms to the problem at hand." In this context, I think of "crisply defined" as being when know the algorithms, and input/output format, and want to get things working together. I still don't find TDD useful. Even in that case, I much more a spike-then-stabilize developer, with most of my tests added at the end, followed by coverage analysis to identify missing tests. (And I don't believe for a minute the claims of TDD supporters that TDD naturally leads to 100% coverage.)
- 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".