4 ms·

>or any style of automated tests, really, you don't really have to be driven by them Looks like you misunderstood what TDD is. TDD is not a method of testing,

>or any style of automated tests, really, you don't really have to be driven by them Looks like you misunderstood what TDD is. TDD is not a method of testing, it's the method of design of system architecture, in which you formalize the contracts and design APIs by writing examples of their use in tests. Because of that TDD is applicable on every scale (e.g. even when you design complicated algorithm that can fit in just couple of screens) and because of that TDD must be compared not to other test methods, but to other methods of design. Of course, that comparison will not show the supremacy of TDD for many reasons, like, for example, insufficient expressiveness of testing framework or domain specifics. TDD is useful as one of the many tools we have today, but it shall never be the only tool.

spatulon 10y ago
This benefit of test-driven design is not obvious (at least it wasn't for me) until you really experience it. Several years back I wasn't aware of the concept of dependency injection, but independently discovered it while trying to unit test some error logging functionality. Previously I'd always used a global/singleton logger object. That always felt wrong, but I always assumed it was necessary until writing unit tests forced me to avoid that design. Also note that TDD is not the only way of getting this benefit. IMHO Paul Graham's essay Programming Bottom Up[1] and Casey Muratori's concept of 'compression-oriented programming'[2] both espouse this same idea of improving API design by "writing examples of their use." [1] http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html [2] https://mollyrocket.com/casey/stream_0019.html https://mollyrocket.com/casey/stream_0019.html
- ivan_gammel 10y ago
  Well, I practiced TDD for no less than 10 years, and its benefits are still not obvious, more like something that needs to be continuously reviewed in the context of the current work. Once you've understood all the design patterns that TDD enforces, you don't need TDD to use them. You just think how you _would_ test your code and defer test implementation for future.
  - platz 10y ago
    Why not just learn the patterns directly?
    - ivan_gammel 10y ago
      :) Who said they should not be learned directly? TDD is just a good demonstration of their use.
mempko 10y ago
While you are right that TDD is about design, and that it creates examples of use and contracts in a sense. There are better methods for this purpose like Design by Contract which in my opinion is a superior method. Why? Mostly because TDD process of red-green-refactor is an evolutionary process. Like taking mother nature to design. It's un-intelligent design....hahahha

spatulon 10y ago

This benefit of test-driven design is not obvious (at least it wasn't for me) until you really experience it. Several years back I wasn't aware of the concept of dependency injection, but independently discovered it while trying to unit test some error logging functionality. Previously I'd always used a global/singleton logger object. That always felt wrong, but I always assumed it was necessary until writing unit tests forced me to avoid that design. Also note that TDD is not the only way of getting this benefit. IMHO Paul Graham's essay Programming Bottom Up[1] and Casey Muratori's concept of 'compression-oriented programming'[2] both espouse this same idea of improving API design by "writing examples of their use." [1] http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html [2] https://mollyrocket.com/casey/stream_0019.html https://mollyrocket.com/casey/stream_0019.html

ivan_gammel 10y ago
Well, I practiced TDD for no less than 10 years, and its benefits are still not obvious, more like something that needs to be continuously reviewed in the context of the current work. Once you've understood all the design patterns that TDD enforces, you don't need TDD to use them. You just think how you _would_ test your code and defer test implementation for future.
- platz 10y ago
  Why not just learn the patterns directly?
  - ivan_gammel 10y ago
    :) Who said they should not be learned directly? TDD is just a good demonstration of their use.

mempko 10y ago

While you are right that TDD is about design, and that it creates examples of use and contracts in a sense. There are better methods for this purpose like Design by Contract which in my opinion is a superior method. Why? Mostly because TDD process of red-green-refactor is an evolutionary process. Like taking mother nature to design. It's un-intelligent design....hahahha