3 ms·
"I use it on occasion as a good sanity check to make sure I didn't break anything too obvious" That sounds more like unit tests than TDD. With TDD you should a
by _puk 9y ago
"I use it on occasion as a good sanity check to make sure I didn't break anything too obvious"
That sounds more like unit tests than TDD. With TDD you should already know that you didn't break anything..
If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input; it is not however going to determine if you did that in the best possible way.
- deleted 9y ago[deleted]
- eropple 9y agoThis is a good and cool post. TDD is less susceptible to "sucky code" for two reasons: 1) It should be a direct port of your specification. If you don't have a specification, you can't do TDD. 2) It should be written by someone who won't be writing the code. Or, at minimum, checked over by someone who won't be writing the code. Writing tests after you've written code strongly encourages you to write implementation tests rather than specification tests. Both are important and useful, but for separate things (if you have to change your specification tests it's probably because you need to bump a minor or major version number for your software).
- ams6110 9y agoTDD will as often as not (and maybe even mostly) surface errors (or gaps) in the specifications rather than errors in the code.
- eropple 9y ago100%. This is perhaps one of its most powerful attributes. Whether I have a spec written on paper or one I've informally defined in my head, I very often find myself enumerating the potential failure cases (determining the domain and range of my code, as it were) and going "hey...wait a minute...what about X?". Writing tests after code is completed, on the other hand, lends itself to reifying an implementation as "correct" and divergence from the implementation as being wrong. No bueno.
- lgunsch 9y agoRegarding your second point, it is not only very difficult, but also not even how TDD was designed to work by its original creators at all. It is specifically not written by other people. TDD, as outlined by the one who created the technique, as well as other big proponents such as Robert Martin, is done in tight 2 or 3 minute loops. As Kent Beck says, if you can't write your test in 5 minutes, you're doing too much.
- eropple 9y agoHow "its creators" designed it to work, and how I find it to work in practice, are pretty different. I've found that having two people understand a spec to the level where they can reason about it (and that the best artifact for demonstrating that reasoning is a test suite) is the most straightforward way to build reasonably correct code. (I mean, heck. Theoretically, Agile's "creators" designed it to be useful and helpful to developers. Cue sad trombone sound.)
- falcolas 9y ago> If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input Well, if you suck at writing code, what guarantees do you have that the tests (which are also code you write) are even correct?
- deleted 9y ago[deleted]
- AnimalMuppet 9y agoYou don't have any such guarantees. But your test would have to be broken in the same way that your real code is broken, not in some different way.
- falcolas 9y agoWell, if the test is accidentally testing the wrong input/output pairs, your code can pass the test perfectly and still be broken. Especially if you follow the "build to the test" mantra.