First off I love TDD. I get more satisfaction out of my code when I write the tests first. I feel like I fly through my task list and my mistakes are few and far between.
Second, I don’t do much TDD. If it’s something I’ve done a million times before, then I just write the code. But there’s always that one little bug that takes time to root out and find, even though I’m an expert on this or that. TDD, I have very few bugs during and QA finds even fewer bugs after. No TDD, there’s always something. And even if it only takes me 2 minutes to find the bug, that’s 2 minutes too long, not to mention the tester’s time I’ve wasted. Shame on me for being so darn brilliant.
I think a key difference between the people who embrace TDD and those that don’t is your comfort level with code. I mean raw code, semicolons etc. If you use whiteboards and/or UML first, or need to get a rough design doc on paper before you can commit to code, then TDD probably doesn’t resonate the same way. If code is your first language and you have to translate that to english to talk to other human beings, then for you, tests are the only form of design you can really embrace. They’re always accurate, and let’s face it, you don’t trust design docs or comments anyway.
Now I’m also a huge refactorer and I like nothing better than ripping up huge chunks of code to accomodate a new wrinkle in the requirements. At that point TDD hurts, at least until you embrace the delete key. Those tests are going to need hours of rewrites? DELETE. First find the lowest higher level above the construction zone and make sure you have a safety net. Then just blow the rest away. TDD the reconstruction, or not, who cares? The tests are there to help you along, not hold you back. I’ve got the behavior I want to enforce at some level and if that doesn’t break I don’t really care what happens below now. Sprinkle in unit tests in whatever fashion you please until you feel good about the code.