Getting hands dirty on TDD

In my experience on Test Driven Development (TDD), while developing a small application from scratch in .NET, it requires PnP - "Patience and Practice" to adapt to this "Test-First" way of coding. I would rather term it as "code to test the code" methodology which doesn't require so much of mental change or paradigms shift but rather patience to try out new and better way to write quality, easy to read, finer code.

Along this journey of TDD, which I have recently started and still on my way, have learnt
simplicity. TDD, if followed religiously, by itself brings out simplicity in your design and code.

The key advantage that i felt TDD gives you is feedback. You write a failing test case, make it pass, and then you formulate the next test case. The wonderful thing is that when you get to that next test case, you have the feedback from getting the first one to pass to draw upon. Often that feedback will lead you to formulate the next test case in a different way. It could even lead you to produce a different interface for the class you were writing.

I still have to try and get my hands dirty on enhancement application/project to learn and share more on experience using TDD in such scenarios.

.......(One of the comment posted on Weblogs Forum by Richard Jonas)
If you don't understand the requirements of the project at all, you need to have a way to get these under control first. Writing tests in advance is a good way to think about the requirements of the problem and establish the questions you need to ask others.
If you really understand a problem well and are sure exactly how you are going to do it (if it's well specified and something you've done lots of times before), a process with a lot of control such as TDD makes the development more reliable.