4 ms·

TDD ensures your system/application is testable, that's it, and that's all. Seriously. TDD does not, nor ever has, said anything about the quality of the desig

TDD ensures your system/application is testable, that's it, and that's all. Seriously. TDD does not, nor ever has, said anything about the quality of the design. It merely says it will be testable. While a design that is testable may not be "the best" design (presuming some agreed-upon ordering of goodness of design, which there isn't), it is at least testable and can be proven to work as intended. That, in the end is what this is all about. Do you go with what people feel is the best design but you can't prove the result, or do you go with what people feel is the poorer design but you can test the result and prove it works? Make this decision as though your life and/or life savings depended on it.

tmaly 3y ago
I agree with your statement. I think where TDD may not work well is with legacy systems where people try to bolt on tests after the fact. I get the impression from the article that this might be the case.
- taylodl 3y ago
  If legacy systems weren't designed to be tested then it can very well be that they're very difficult to test. I've never seen anyone try to apply TDD to projects modifying those systems. Seems like it'd be an exercise in frustration!
  - sprucebruce 3y ago
    There's a great book by Michael Feathers on this very subject called "Working Effectively with Legacy Code". He takes a strong "test first" approach and talks about all the work you have to do when working on a system that isn't testable to change it safely with TDD.
    - taylodl 3y ago
      Thanks for the info! I'll check it out.
switchbak 3y ago
Agreed, but I’d soften the language on “proving” it works. Often we’re providing an assurance that a complex system works with the combinations of examples and inputs we’ve provided. There are approaches to provide much stronger assurances, both on the testing and implementation sides, but they’re typically outside the scope of pure play TDD. And I’ll take a decent assurance over the lack of one any day of the week.
sprucebruce 3y ago
It's very common for TDD advocates to claim that testable code is good code - or at least better than it otherwise would be. I don't think that's actually a wild claim. However, I don't think TDD even ensures testability, especially in javascript/node and similar languages. You can always use goofball mocking frameworks, reflection, and monkey patching to brute force a test into working. That's what I wrote this blog post about. I see real wonky tests a lot, and am confronted by test automation skeptics with bad past experiences, and so I wrote the blog post really for that audience and also for the people who _DO_ claim TDD forces a high quality design.

tmaly 3y ago

I agree with your statement. I think where TDD may not work well is with legacy systems where people try to bolt on tests after the fact. I get the impression from the article that this might be the case.

taylodl 3y ago
If legacy systems weren't designed to be tested then it can very well be that they're very difficult to test. I've never seen anyone try to apply TDD to projects modifying those systems. Seems like it'd be an exercise in frustration!
- sprucebruce 3y ago
  There's a great book by Michael Feathers on this very subject called "Working Effectively with Legacy Code". He takes a strong "test first" approach and talks about all the work you have to do when working on a system that isn't testable to change it safely with TDD.
  - taylodl 3y ago
    Thanks for the info! I'll check it out.

switchbak 3y ago

Agreed, but I’d soften the language on “proving” it works. Often we’re providing an assurance that a complex system works with the combinations of examples and inputs we’ve provided. There are approaches to provide much stronger assurances, both on the testing and implementation sides, but they’re typically outside the scope of pure play TDD. And I’ll take a decent assurance over the lack of one any day of the week.

sprucebruce 3y ago

It's very common for TDD advocates to claim that testable code is good code - or at least better than it otherwise would be. I don't think that's actually a wild claim. However, I don't think TDD even ensures testability, especially in javascript/node and similar languages. You can always use goofball mocking frameworks, reflection, and monkey patching to brute force a test into working. That's what I wrote this blog post about. I see real wonky tests a lot, and am confronted by test automation skeptics with bad past experiences, and so I wrote the blog post really for that audience and also for the people who _DO_ claim TDD forces a high quality design.