rssvihla

I can put in 2 cents here. It makes you think about your API up front. Can you do that others ways (write your documentation first, etc)? Of course so do the approach that works for you. TDD just happens to be my preferred approach.

As for "especially because it emphasizes unit testing" that doesn't mean it frowns on integration or acceptance testing. In fact most practitioners I know write high level end to end tests for the core functionality.

I hope you can appreciate TDD is not terrible for all developers and that possibly there is something useful in there for some people. As you imply there are many paths to quality software. You risk being as guilty as those you criticize if you try and claim others are "less than" that can produce decent code in a different way than you believe is possible.

TDD definitely has been _very_ positive for my software and there really is no comparison between what I did before and what I've done since as far as bug rates, customer satisfaction, and time to completion. I'm sure you'd agree that those are positive outcomes.

I appreciate you've had lousy examples and that maybe even the majority of TDD practiced is a lousy example. However, the examples you give and what you're describing from these consultants is not remotely the way I've done TDD for the last 5 years. I work extremely hard on refining the concept of testing and when and where to apply different approaches.

As for "you're unlikely at that point to want to go back and change things". I make way more changes in my code and tests before TDD than without. Granted I did spend a year learning how to write tests that hit the right boundaries and wouldn't break everything when I did change architecture strongly. I think any developer needs to dive deep into HOW TO TEST anyway test first or after.

Also, I don't know why anyone would have a hard time deleting code that no longer applied. There is always source control if you really feel like you need it again.

as for "and then it turns out that you relied on an architecture that you don't want to use"

Many TDD practitioners have this concept called "spikes" which is code that you write without tests to get a good idea of how that particular algorithm will work for you and what approach you want to take. However, its throw away code that's is often very procedural and is more just thinking through an issue. This minimizes some of the shifting architecture pain you're referring to.