I love Test Driven Development. I love how it naturally improves my code by forcing me to write testable functions, and clear interfaces. I love how tremendously satisfying it is when a new feature request comes in for a section of code that has solid test coverage, knowing that as long as I can produce and satisfy a test that mimics the new feature, without breaking other tests, I have reasonable assurance I'm not breaking something else. The same thing goes for bug reports.
My thoughts around practicing TDD when learning a new language or framework are changing a bit. I'm not sold that TDD is great in those situations. When climbing the learning curve of a new framework, there's enough to wrap your mind around to simply get some code working. Adding all of the additional know-how necessary to also test-drive that code can be very frustrating.
For example, as I was learning Rails, here are just some of the additional tools I needed to learn and choose between to properly test-drive a web app:
It was freeing for me to just focus on learning Ruby, and learning Rails. Granted, at the sacrifice of untested code, complex code. I think as long as the end goal is to become proficient in a TDD style workflow, that it's perfectly fine to forget about the tests initially. As the new language or framework becomes more natural, add in once piece of the testing puzzle at a time, and stick with it. Then, as your brain allows, add in the next, and so on.
Written by Alex Brinkman who lives and works in Denver, but plays in the mountains.