DevOps Zone is brought to you in partnership with:

George Dinwiddie is an independent software development coach who helps organizations, large and small, to increase the effectiveness of their software development efforts. He provides guidance over a broad range, at the organizational, process, team, interpersonal, and technical levels. He is currently crusading to break down the barriers that hinder effective collaboration between the business, the programmers, and the testers. George is a frequent speaker at Agile conferences. George is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

Why I Practice TDD

07.24.2013
| 6012 views |
  • submit to reddit

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.

Published at DZone with permission of George Dinwiddie, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Douglas Rathbone replied on Wed, 2013/07/24 - 8:48am

I am a big supporter, although given that development is broadening by the day technology wise, I am left feeling like TDD suites some skill sets better than others.

I assume you do TDD using Java, c#, c or similar - not fully integrated ajax websites with service layers across mutiple technologies (maybe a node service, c# web api layer and a ruby front end). the integrations in modern programming are where TDD starts to become harder to do while maintain productivity.

Great post though.

George Dinwiddie replied on Wed, 2013/07/24 - 8:18pm in response to: Douglas Rathbone

Hi, Douglas,

Are you saying some people don't have the skill to do TDD?

I've test-driven Java, C#, Ruby, Javascript, and Bash scripts. You're right that using a mix of technologies makes it more work to refactor across those technology boundaries, but it can be done. In fact, in my embedded system days I used to move functionality between hardware and software (in either direction, depending on the tradeoffs).

Loren Kratzke replied on Thu, 2013/07/25 - 12:33pm

 I think Douglas might be referring to the observation that TDD is kind of a happy path procedure that works best when designing Java code that is client to other Java code and has other Java code as clients. It becomes complex when you start crossing domains.

I personally do not practice TDD. It works well for some people but to me it is ridiculous to think that every new piece of code, library, or project should begin with a failing test. Call me old fashioned, but that dog doesn't appear to hunt. My mind simply does not work that way at all.

I don't need to put a pressure gauge on an empty inner tube before I fill it to know that it is empty.

I have been coding for 30 years, long before TDD was ever an acronym. Engineering is an art and I would never pin down any single design methodology as better than any other methodology. That said, it is possible that I have internalized the TDD process along with other creative processes to the point that external TDD appears as incomplete, inefficient, and as only one tool in the box, not even my preferred tool either. My code is testable, but my design process is not driven by testing. As long as nobody calls me "wrong" for being that way then I am happy.

Unfortunately, many people want to push TDD as the "proper" way of designing software and some wish to formalize and institutionalize it, making it an organizational prerequisite for being hired, and judge an individuals performance on their ability to comply with TDD practices. That would be a sad day indeed.

To each his own. That is why I personally do not practice TDD.

George Dinwiddie replied on Thu, 2013/07/25 - 2:18pm in response to: Loren Kratzke

Hi, Loren,

I've been coding for more than 30 years, also. I'd been coding for more than 20 years when I first tried TDD. At the time, it made no sense to me. It was not "the way my mind worked." It didn't seem useful or even possible. But, people I respected made it work and found it valuable. So I finally tried it.

In three days, I proved to myself that I could do it, and that it made some things easier. It took much longer than that to become good at it, of course.

I can assure you that you haven't "internalized the TDD process" without practicing it. I suspect you don't really know what it is. It's not a "methodology." It is another tool in the toolbox. If you'd prefer to only use the tools you collected years ago, that's certainly up to you. It's fine with me if you don't try TDD.

It's curious, though, that you find it important to publicly announce that you won't do TDD. I'm not sure what you gain by that. Are you trying to convince others it's not worth trying? Are you trying to convince yourself you don't need to try it? Your pronouncement doesn't sound happy, to me. It sounds bitter and defensive. That, to me, is what's really sad.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.