Why I Practice TDD

I was reading Laurent Bossavit’s book, “The Leprechauns of Software Engineering—How folklore turns into fact and what to do about it,” and came across his mention of “Comparing the Defect Reduction Benefits of Code Inspection and Test-Driven Development” by Jerod W. Wilkerson, Jay F. Nunamaker, & Rick Mercer. This struck me as an odd thing to study. Not only is Test-Driven Development not primarily about defect reduction, but the populations of defects it might reduce are likely to be very different from population of defects reduced by code inspection.

I then took a look at my own list of TDD studies and noted that most of these studies were focused on external quality as measured by absence of known defects, and time it took to develop the functionality. Keith Braithwaite, at Agile 2007, reported on internal quality, specifically Cyclomatic Complexity.

Quality and productivity are, of course, important things. And they’re easy to sell to some managers. Who could be against them? And I certainly wouldn’t continue to practice Test-Driven Development if it added defects or took a significantly longer time to create functionality. But that’s not why I practice TDD.

“Wherever we want to go, we go. That’s what a ship is, you know. It’s not just a keel and a hull and a deck and sails. That’s what a ship needs. But what a ship is…what the Black Pearl really is…is freedom.” ―Jack Sparrow

And so it is with Test Driven Development. It’s not just a test, implement, refactor cycle. It’s freedom. It’s the freedom to start working toward my solution before I can map it all out. It’s the freedom to clear my head of the details because my tests are keeping track of them for me. It’s the freedom to make changes knowing my tests will alert me if I’ve violated a previous assumption that I’ve forgotten. It’s the freedom to deliver code I can trust to work the way I think it does. It’s the freedom of knowing I can correct my error without rewriting all the parts that do work when I make a boneheaded mistake. It’s the freedom of feeling confident I can push my code into whatever shape I need, because I’m used to doing that every day.

I think back to the day I first tried TDD. If I’d been told to do so because it was beneficial to the company, I might not have been terribly interested. Instead, I wanted to try it because programmers who seemed smarter than me said they found it beneficial. I tried it to see if I could reap the same benefits.

Perhaps the slow uptake of TDD in the industry is due to it being touted as something you should do. Like exercise and moderate eating habits, we’re wary of things weshould do. A New Yorker article, “Slow Ideas” by Atul Gawande, speaks of the different rates of adoption of surgical anesthesia and antiseptics in medicine. Doctors’ use of anesthetics rapidly spread, but antiseptics spread much more slowly. One of the key differences between the two is that “although both made life better for patients, only one made life better for doctors.”

I’m here to tell you that Test Driven Development makes life better for the programmer. That’s the reason I practice it.