For a lot of people, TDD (read -- both Test Driven Development and Test Driven Design) is a software practice that one couldn't and shouldn't live without. Carefully double-checking your code by building a test harness has many benefits even if there is only one developer on the project. I can recall countless examples of how my unit tests have saved missteps that I would have otherwise missed and probably spent a lot more time debugging after deploying to an application server. I have always wondered, and I have not seen enough results to indicate one way or another, whether TDD is being accepted in some development circles because people genuinely find it useful, or because it's a buzzword and the going software fad. My anecdotal experience lends me to believe that TDD is thrown around more as a buzzword and used less as a valuable tool.
The way I see it, there are a handful of developers who use TDD because they find it genuinely helpful, a lot that use TDD because that's the accepted buzzword of the moment and they wish to fit in, and still some more developers that have seen buzzwords come and go, so they're not interested in getting caught up with some fad that appears to take a lot more time to get things done. They want to arrive at work, get things done with minimal hassle, and meet their deadlines.
And I don't blame them, or the reasoning for their stance. Especially when you consider the approaches used for pushing TDD. Which leads me to my open-ended question:
How do you convince your co-workers that TDD is a good thing
My observations for how TDD is sold to prospective developers is the following:
- Overhyped, sold to developers who soak up the buzzword technologies and then run with it This usually happens when a developer reads/listens to a self-appointed industry thought leader, interprets the words, energy, and intentions of said thought leader into their own evangelistic ideas and attempts to sell their new-found magic potion.
- Hyped, but sold with very vague details This is usually a result of the first bullet and not completely understanding the intentions of TDD, but then trying to sell it to someone else.
- My approach is better than yours Injecting enough technical arrogance into the discussion, in an attempt to convince your fellow developer that your way is better than theirs and they should adopt your way