I’m a big fan of TDD; I’ve loved it since the first moment I scratched the surface. It puts the software development process in a new light, like looking at your code from a whole new perspective. A perspective that is more similar to what you experience while learning a third party API, rather than developing a class bottom-up.
It is as if you are learning your own API (class) while you develop it. And you tweak it to be exactly what you want it to be while it is growing, changing signatures to methods, names, refactoring all along the way.
The end result is often surprisingly simple. What you need, and nothing else.
Anyway, there is an aspect to TDD that is not brought up that often IME. It is the following observation:
If a class is test-covered, you can do brutal optimizations as long as you like, experimenting away, without worrying about breaking the code.
This is similar to the argument about bug fixing test-covered code – you may refactor away to make the code read better, be more understandable, and feel quite certain you are not breaking anything. The difference is that optimization tend to obfuscate code, not make it more readable!
TDD is the optimizers dream!