Agree. To me this smells like a lack of experience. TDD is what it is--for some parts of the process, I don't think it's appropriate--just like other "Extreme

Agree. To me this smells like a lack of experience. TDD is what it is--for some parts of the process, I don't think it's appropriate--just like other "Extreme programming" practices. But TDD certainly has helped me write cleaner, simpler code in the past, and having a set of regression tests to fall back on has saved me time and time again (which, let's be clear, is separate from TDD). In fact, I spent this morning writing a good bit of TDD code, and in the afternoon felt like I had to finish something up and foolishly eschewed the testing ("I'll write 'em later!" right)...and I ended up spending more time mucking about with stupid errors, and ironically in the end wrote less code. This is anecdotal, but it has happened to me a good number of times. As a result, I tend to prefer TDD when I can use it. Sometimes I like spiking out a solution first, if I don't fully understand the algorithm, for example--but then I will often scrap it and re-write it with tests, which usually produces a more clear statement of the solution since I have already thought through it. From which follows my next point: of course writing tests, and TDD in particular, does not preclude thinking hard about your code's structure. But without experience testing, and especially doing TDD/BDD, I feel that it is very hard to understand the tradeoffs and challenges involved, as well as the pluses. So when I hear either a vehement denouncement or statement of support, I tend to suspect a lack of experience more than anything else. Although, I suppose Uncle Bob is a special case...