TDD Is a Tool, Not a Religion

Catching Up

The internet is abuzz since DHH's blog post: TDD is Dead.
There have been many responses, including many by Bob Martin.

Breaking News

The latest new entry to the saga is a video conversation on YouTube where DHH, Martin Fowler and Kent Beck discuss the virtues and pains of test driven development. Definitely worth watching.

Subjective Summary

1. TDD scratches an itch. It's one way to make you feel good about your work, confident that it works as intended, every step of the way. 
2. TDD does not work well for all problems, like when the output is unknown or unquantifiable.
3. Self-testing code (programmatic & repeatable) is highly desirable, but TDD is not the only way to get there.
4. Heavy use of reflective mocking can tightly couple tests to implementations, counteracting one of the primary reasons to have tests: to enable refactoring. (Bob Martin has some thoughts on when and how to mock.)
5. Programming has many trade offs (testability, maintainability, usability, speed, etc.), and it is important to keep them all in perspective, re-prioritizing as needed, without becoming myopic.

Corollary

Just because writing unit tests and making them pass is easier and provides faster feedback than end-to-end tests doesn't mean unit testing is more important. It's critical that good unit design doesn't come at the cost of good system design.

I'll leave you with my favorite list of Object Oriented Design Principles. As with most sets of goals, it's impossible to satisfy them all all the time, but it's important to keep them all in mind, and know when to apply them.