= 27d567bc2d48d9f40e9ccc20ea370b15)
sketerpot comments on Coding Rationally - Test Driven Development - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (82)
One of the best examples of when TDD doesn't apply is when you're writing a version 0 that you expect to throw away, just to get a feel for what you should have done. When you do that, screw extensive test suites and elegance and maintainability; you just want to get something working as quickly as you can, so that you can get quickly to the part where you rewrite from scratch.
Often you can't really know what the issues are until you've already run afoul of them. Exploratory programming is a way of getting to that point, fast. You can bring out the tests when you've got a project (or piece of a project) that you're pretty sure you'll be using for a while.
There are two problems with this idea. First, I've found TDD to be extraordinarily effective at helping break down a problem that I have no idea how to solve. That is, if I don't even know what to sketch, I sometimes start with the tests. (Test-Driven Development By Example has some good examples of when/why you'd do that.)
Second: we can be really bad at guessing whether or not something will get thrown away. Rarely does version 0 really get thrown away, and so by the time you've built up a bunch of code, the odds that you'll go back and write the tests are negligible.
That's a choice. Some of us deliberately throw away the first draft for anything that matters, no exceptions.