I would say that TDD is difficult, but not impractical. If we're talking about designing new code, using TDD correctly will give you an easier to maintain codebase. A criticism I've heard which could be interpreted as impractical is that it's slow; This depends if you're writing software (malleable, long-life code) or a throwaway project. TDD involves investment, and that can be at odds with a 'move fast and break things' attitude. But maybe thats not what you mean?
Whenever you have no idea what solution you're aiming for, TDD is a perfect tool for getting to a solution IMO: The process allows you to break down a problem - firstly so that you understand the problem (if you don't understand it well enough to write a test, then more investigation into the problem that you're trying to solve is needed, otherwise, why write any code? For what purpose?) and secondly, so that it's easier to test, and the tests guide you to a working implementation of the behaviour you want.
Re the legacy code point, for sure, test coverage gives you the safety to refactor. This doesn't necessarily fit with my understanding of what TDD is though, because in that scenario the design is already done, we're simply providing coverage for the existing design? But I've seen TDD used within a legacy codebase to make changes and build features so it is possible!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for your discussion Leonid!
I would say that TDD is difficult, but not impractical. If we're talking about designing new code, using TDD correctly will give you an easier to maintain codebase. A criticism I've heard which could be interpreted as impractical is that it's slow; This depends if you're writing software (malleable, long-life code) or a throwaway project. TDD involves investment, and that can be at odds with a 'move fast and break things' attitude. But maybe thats not what you mean?
Whenever you have no idea what solution you're aiming for, TDD is a perfect tool for getting to a solution IMO: The process allows you to break down a problem - firstly so that you understand the problem (if you don't understand it well enough to write a test, then more investigation into the problem that you're trying to solve is needed, otherwise, why write any code? For what purpose?) and secondly, so that it's easier to test, and the tests guide you to a working implementation of the behaviour you want.
Re the legacy code point, for sure, test coverage gives you the safety to refactor. This doesn't necessarily fit with my understanding of what TDD is though, because in that scenario the design is already done, we're simply providing coverage for the existing design? But I've seen TDD used within a legacy codebase to make changes and build features so it is possible!