Test-driven development (TDD) is a topic that never gets old among programmers, even though we can hardly agree on what its costs and benefits are. While there are no shortage of neatly packaged expert viewpoints on this topic, very few of them are backed up by solid evidence. Formal research indicates that TDD does tend to produce code with fewer defects, but no other significant effects have been found. What these results tell us is that the burden of proof is on us for everything else we believe about TDD, especially when it comes to perceived benefits that have nothing to do with regression testing.

Thinking about my own relationship to test-driven development, I came to realize that my own assumptions about its costs and benefits were fuzzy at best. I had plenty of opinions on the topic, but found it hard to elaborate on them. As these opinions hardened into beliefs, it became much more challenging to meaningfully consider ideas about TDD which differed from my own. My own cynicism was preventing me from making a reasoned argument for my way of doing things.

Knowing that stubbornness is the enemy of progress, I decided to take a fresh look at my use of TDD and how it effects my work. For a period of 90 days, I challenged myself to practice formal TDD as often as possible, and to learn as much about it as I could during that time. While the original plans for my self study were much more rigorous than what I ended up doing, I did maintain a fairly disciplined TDD workflow throughout the three month period, and that taught me a few lessons worth sharing.

To make it easier for us to discuss what I’ve learned, I’ve decided to break the lessons out into individual mini-articles, each with their own comments thread. Please follow the links below to read them:

If you feel there are other lessons that you have learned from your own work with TDD, or you have general questions about how my self-study went, feel free to share them here.