[kureimoru]

I would like to point out that TDD isn't really about tests, it's about design of your program. It forces you from the very beginning to deal with really important questions: how do one use a piece of your program? Is it easy, clear and simple? Can it be tested? What do you expect from the program? Is your program or component overcomplicated?

Design your programs from top to bottom fleshing out details as you go. Deal with one abstraction at a time. And when you're finished you can throw away non-critical tests so that they don't outlive their purpose.

Do remember that tests are code too and that they have to be maintained and that they can become a part of technical debt. Do not use TDD for prototypes when you really don't know how or why implement your program. Create a prototype, explore possibilities, throw the prototype away and write a production version with TDD.

[collyw]

A lot of the time (certainly in my work) the requirements are incomplete / vague enough, that it is easier just to build a prototype and work from there. As such tests will just require two or three times as much code, and there is a fair likely hood that they will be thrown way afterwards.

I know this does not fit waterfall or TTD / agile methodology, but I am certain that there is a very large percentage of IT workers that have to work this way.