There is this old programmer.reddit post (http://programming.reddit.com/info/1kth0/comments) about an XP/TDD "guru" who does "exploration" with unit tests and another developer (a real guru this time, no quotes around the word) who doesn't.
TDD is a valid technique when it fits. What's annoying is this tendency on the part of some of its practitioners to make it out into some kind of panacea.
I'm a guy who's supposed to know all about TDD (I teach organizations how to run software teams) so I hope I don't jump the shark with this comment.
I just have a hard time seeing TDD in all cases. As one commenter pointed out, some systems evolve and some are specified. Evolving systems have execution units (classes, modules, etc) that can change a heckuva lot. Specified systems don't. On a specified system, you know within 80% or so what your hunks of stuff are.
Now I've coded a lot of specified systems. No, you don't design every little detail, that's not what I'm saying. But if you're writing code to balance a checkbook you're not going to end up with a program to make spaghetti. In the startup world, you very well could end up somewhere in a completely different problem domain. Whatever happens, I wouldn't want the testing structure to get in the way of the best design, simply by making it so hard t do heavy refactoring.
What's good about it is that it also serves as a requirements spec, and since it's more flexible - it doesn't feel as tedious. There are already mult implementations in most major languages
There is this old programmer.reddit post (http://programming.reddit.com/info/1kth0/comments) about an XP/TDD "guru" who does "exploration" with unit tests and another developer (a real guru this time, no quotes around the word) who doesn't.
TDD is a valid technique when it fits. What's annoying is this tendency on the part of some of its practitioners to make it out into some kind of panacea.