Test Driven Design: some myths as to why it shouldn't be used

Actually the myths aren't just to do with Test Driven Development (TDD), but are also about writing automatic unit tests after you write the real code. (If you use TDD, you write tests before real code and let the tests drive your design.)

Myth #1: "The customer doesn't want us to add automatic tests. We have asked him."
I think it's quite likely that what they did ask was if it was alright to let the timetable slip a bit so that they could add automatic tests. It might even be so bad that the customer tells them to write correct code instead.
As I see it, this isn't something the customer should be asked about as it is all part of our professionalism. In my experience, not using TDD (or at least automatic tests) most often causes the timetable to slip much more than when I have used it. From beginning to end, I think using TDD makes me more productive, not less.

Myth #2: "We don't have any good tools for automatic testing."
Whether to test or not to test isnít about tools, itís about a mindset! Besides, nowadays there are loads of good tools, the most common one probably being NUnit. And if you still donít find the tool you need, write your own.

Myth #3: "There's no point me testing my own code."
Sure, it's likely that others will find errors that you wouldn't find by yourself (this is one of the points of reviewing.) Still, I think it's our responsibility to take away as many bugs as possible, and this way the QA department (if you're lucky enough to have one) can focus on trickier stuff. And if you use automatic tests, it costs very little for you to run the tests after each and every change.