Reading over the responses to this question Disadvantages of Test Driven Development? I got the impression there is alot of misunderstanding on what TDD is and how it should be conducted. It may prove useful to address these issues here.
IMHO The biggest misconception about TDD is that: time spent writing and refactoring tests would be time lost. The thinking goes like "yeah, a test suite is nice, but the feature would be complete much faster if we just coded it".
When done properly, time spend writing and maintaining tests is saved multiple times over the life of the project in time not spent debugging and fixing regressions. Since the testing cost is up-front and the payoff is over time, it is easy to overlook.
Other big misconceptions include ignoring the impact of TDD on the design process, and not realizing that "painful tests" is a serious code smell that needs fixing quickly.
Just chucking another answer in the pot.
One of the most common misunderstandings is that your code is fixed, ie. I have this code, now how on earth will I test it? If it's hard to write a test, we should ask the question: how can I change this code to make it easier to test?
Why..?
Well The sort of code that's easy to test is:
If we write code like this, testing is a doddle. The interesting thing is that code that is easy to test is, coincidentally, better code.
Better as in easier to read, easier to test, easier to understand, easier to debug. This is why TDD is often described as a design exercise.