> And "as any fule kno" [sic], this is idioicy during a design or hacking or greenfield phase of development. When you write something you run it to make sure

> And "as any fule kno" [sic], this is idioicy during a design or hacking or greenfield phase of development. When you write something you run it to make sure it works. Bottle that and call it a test. And then merely do this before you write the code. "What will I be done when I get this code to do?" Don't plan, and spec, your whole API before you've written a line of code or anything, but do write a one-liner to check whatever it is you're going to do so you know when you're done. Ideally you'll write a test (still just a one-liner) for every corner-case that you cover in code, because you need a failing test to know if your fix actually worked. And face it, if you're doing "real" development work you've got business goals, and a spec with features intended to deliver on that, and you need to cover every tiny detail. If you don't have the spec ('fail on values over n') directly linked to the code that implements it, it will get lost, and if you aren't testing it you can't legitimately claim to be delivering it. A spec, such as you'd get by performing useful TDD, is a requirement for modern software development. You could write it all up-front in the planning phase (waterfall style), or all after in the testing phase (waterfall style again), or you could interleave it with research and development, which if you think about it, sounds kind of agile by comparison...