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 we should 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.

Post to Twitter Post to Plurk Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to MySpace Post to Ping.fm Post to Reddit Post to StumbleUpon

Comments (12) to “Why I Practice TDD”

  1. I agree completely with you.

  2. Great piece!

  3. Oh gosh. Yes, yes, yes. I tout the other benefits. But maybe I should talk about sanity and peace-of-mind instead.

  4. You make a lot of good points. I still have trouble selling people on the idea that TDD is better for the programmer. I think largely because the rewards take a while to come. You need to practice and become skilled at it (still easier than learning a new language). And the code becomes more flexible but that may not be noticed for months. People are strongly motivated by short term rewards so I like to run Kata’s to build up practice and motivate

  5. Geoff, I’m not trying to sell people that TDD is better for all programmers. I’m saying it’s better for me. It didn’t take long for the rewards to come.

    On my first production project using TDD, I often had people come to me and say my code wasn’t working. When I asked how they were using it, I’d say “I’ve got a test for that. Let me see what you’re doing differently.” Invariably they were doing something silly like calling it with an uninitialized variable. Then the time came when I said, “Huh, I didn’t think of that.” I wrote the test and my code was badly broken. I had made a dumb but fundamental assumption, and thought it would take a week to fix. Instead, because of the tests, it took me half a day. And that included the time pondering what else I needed to do after all the tests were again passing.

    I know it pays off. If people aren’t going to take the time to try it, then I don’t think they’re being very professional. Why wouldn’t you try techniques that work for so many smart people? Then they can make an informed choice as to whether or not it helps them.

  6. Starting to do TDD is tough for programmers that either haven’t had experience with testing frameworks (there’s an alarming number of these programmers out there) or programmers that are simply mired in the “get it done now” organization. I was recently talking with a good friend who is a program manager at a very-large organization. I haven’t worked with him in ten years. When I started talking about what I do and impacts of some engineering practices — he said the organization has had a few people talk about doing TDD, ATDD, even Agile — but they don’t allow it due to time. My jaw hit the floor because I knew that projects there were all backend loaded and the teams always were required to brute force projects across the finish line or they didn’t get out the door. And often when they did, it was with 100′s if not 1000′s of issues.

    That all being said, we know that TDD changes the paradigm of thinking to what do I want this piece of code to accomplish — how should it work. By doing this up front, we are given the freedom to explore better solutions and not just code down one path to get it to work. I have personally found it takes less time, because I can focus on getting one small part of code to work and then move to the next – I’m not all over the place thrashing trying to get multiple points of code to work, and work together. Not to mention, I’m a much better craftsman because I constantly refactor and structure my code to address the ‘ilities.

    This is a great blog post, and I think my favorite line is the in your comment -
    “If people aren’t going to take the time to try it, then I don’t think they’re being very professional.”

    …what he said.

  7. [...] Why I Practice TDD Written by: George Dinwiddie [...]

  8. DZone has republished this post on their site. There are some interesting comments there, also.

  9. This was just great George, awesome really. Enjoyed it lots, agree totally. Freedom. Wonderful thought, thanks for this.

  10. Hello George.
    I am a developer in Brazil.
    I like to translate your post to brazilian portuguese in my personal blog ( blog.rocktto.com) with link to the original.
    Can i translate and publish the translated on my blog?

  11. The Brazilian Portuguese(pt_BR) translation is here:
    http://blog.rocktto.com/2013/07/por-que-eu-pratico-tdd/

    Thanks George. Your text is great.

  12. Thank you for this! It scratched an itch for me, but not quite all the way, so I wrote my own thoughts.

Post a Comment
*Required
*Required (Never published)