3 ms·

A nice clarification that I've heard from Dave Farley is that TDD doesn't necessarily imply not designing your system or architecture ahead of time. You still d

A nice clarification that I've heard from Dave Farley is that TDD doesn't necessarily imply not designing your system or architecture ahead of time. You still do that, it's just that with a more traditional approach, you take that design/architecture and begin implementing it assuming that while you may end up making some changes, it's basically correct. With TDD, you begin implementing your design/architecture just the same except that from the very beginning you assume that your naive design is probably wrong and and leave yourself open to making those large corrections as you encounter the need. He likens it to the scientific method where you start with a hypothesis and then design experiments that would disprove your hypothesis. In my experience, when you approach TDD this way, it remains extremely strategic.

js8 5y ago
> With TDD, you begin implementing your design/architecture just the same except that from the very beginning you assume that your naive design is probably wrong and and leave yourself open to making those large corrections as you encounter the need. I think the assumption that you can test your way out of bad design is false. Design is about assumptions you make, and you cannot test these assumptions, because your tests have to make the same assumptions. In other words, the problem with the scientific analogy is that in science, the model and the world are never going to be the same thing. But in TDD, the model (specification) and code are ideally the same thing. You should make sure they are the same thing and try NOT to deviate from that in the first place. What you can do, however, when refactoring, is to compare old implementation (non-efficient one, for instance) and the new implementation. That is possible, but I rarely see that in TDD approaches (modern testing focus is on one instance of code only).
- AnimalMuppet 5y ago
  > I think the assumption that you can test your way out of bad design is false. Design is about assumptions you make, and you cannot test these assumptions, because your tests have to make the same assumptions. I think that's right. But what TDD buys you is that, when the design changes (and it should, if it's a bad design), and you have to modify your component/class/module/whatever, you can run the tests and see if you broke anything. You can then, for each failing test, think through whether the change should have broken that (and therefore the test is now wrong), or whether your change actually broke something that had been working. This can make it far easier to make changes safely, and lets you make them with far more courage. It means you're not stuck at "we really should change that, but it might break something, so it's not worth it."
  - js8 5y ago
    > But what TDD buys you is that, when the design changes (and it should, if it's a bad design), and you have to modify your component/class/module/whatever, you can run the tests and see if you broke anything. That's not exclusive to TDD, it is true for any automated testing, and not only that. Any formalizing of additional assumptions into the code (as I write elsewhere, things like type checks, assertions, property tests) will also manifest potential issues when code changes. My point is, there are other techniques to solve this problem, more straightforward than TDD.

js8 5y ago

> With TDD, you begin implementing your design/architecture just the same except that from the very beginning you assume that your naive design is probably wrong and and leave yourself open to making those large corrections as you encounter the need. I think the assumption that you can test your way out of bad design is false. Design is about assumptions you make, and you cannot test these assumptions, because your tests have to make the same assumptions. In other words, the problem with the scientific analogy is that in science, the model and the world are never going to be the same thing. But in TDD, the model (specification) and code are ideally the same thing. You should make sure they are the same thing and try NOT to deviate from that in the first place. What you can do, however, when refactoring, is to compare old implementation (non-efficient one, for instance) and the new implementation. That is possible, but I rarely see that in TDD approaches (modern testing focus is on one instance of code only).

AnimalMuppet 5y ago
> I think the assumption that you can test your way out of bad design is false. Design is about assumptions you make, and you cannot test these assumptions, because your tests have to make the same assumptions. I think that's right. But what TDD buys you is that, when the design changes (and it should, if it's a bad design), and you have to modify your component/class/module/whatever, you can run the tests and see if you broke anything. You can then, for each failing test, think through whether the change should have broken that (and therefore the test is now wrong), or whether your change actually broke something that had been working. This can make it far easier to make changes safely, and lets you make them with far more courage. It means you're not stuck at "we really should change that, but it might break something, so it's not worth it."
- js8 5y ago
  > But what TDD buys you is that, when the design changes (and it should, if it's a bad design), and you have to modify your component/class/module/whatever, you can run the tests and see if you broke anything. That's not exclusive to TDD, it is true for any automated testing, and not only that. Any formalizing of additional assumptions into the code (as I write elsewhere, things like type checks, assertions, property tests) will also manifest potential issues when code changes. My point is, there are other techniques to solve this problem, more straightforward than TDD.