4 ms·
> 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 wron
by 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.