Anti-Test Driven Development Arguments and Myths

Ok, I have run into the anti-TDD arguments on and off over the years. Generally it comes from two primary sources. The person who doesn’t want to do TDD no matter what, nor test, nor learn anything about the latest and greatest tech, they simply want left in their corner of the universe to code whatever they are coding until they drop dead. Then there is the other individual who is a decent developer, but just has honest hesitations about the style.

The developer who has honest hesitations I can understand, can talk to, and can usually at least get a “Well, that sounds reasonable, but I’m still not sure” response. Which is much better than the alternative of disregarding TDD outright. The hope, is that this individual can at least try out TDD and see if it would work for them.

Even with the more open minded developer it is still difficult to put TDD into practice. Why? That’s simple, TDD is hard and forces a developer to step back into the basics and really think the problem through first. Most developers (at least currently, maybe it’ll change) have a very “just attack the problem with code” type of response. Often the way to break down problems is taught in computer science 101 level classes, but after that is often lost in all the cramming for math, algorithms, and other such material. But the core fundamental idea of thinking the problem through clearly still needs to be broached. TDD puts that idea forefront in the process by making a developer write the test to verify the problem statement first.

With all this stated, there are a few myths that I’d like to bust. These myths are often what cause the first person to cringe away cowardly in their corner of the universe, and causes these hesitations in the second more open minded developer. After busting these myths I’d hope more of the open minded developers can use the power and thinking that TDD encourages. As for the first corner cringing coder, they’re a dying breed and I wouldn’t bet on their recovery.