I’ve been training people on TDD and the first thing I said is you need to start from the functional spec and then (maybe) create a technical spec that is used to drive the tests. Understand the problem first – and then the tests are just part of writing the code as a whole, no biggie.
Writing small tests for small bits of code make you think small, with short well focussed methods that do stuff. Long linear honkin’ bits of procedural code are very hard to test properly. TDD has the accidental but very useful effect that you write stuff that is’t tightly coupled because it’s impossible to do efficient TDD with tight coupling, assuming you get how to do it well. That takes practice. I think you should give it another try from the beginning with something simple and notice how the structure of your code is better (IMHO anyway).
When I’m doing demos or quick tracer bullet things then I don’t bother, but then there are no consequences.
I agree that agilistas can be far too rigid – don’t substitute process for thought. Anyone who ever suffered under RUP (or any big MC company’s “method”) knows how painful this is.
Testers test functionality. Programmers test assumptions. Not the same.