Last April, I attended the It Will Never Work in Theory: Live! event, which featured a number of fascinating lightning talks. One of particular interest was by Davide Fucci: The hidden costs and benefits of TDD, in which he asks the question:

Are people who claim to do TDD really doing TDD?

To answer this, they observed more than 60 experienced developers while they worked, supposedly using the Red-Green-Refactor approach of TDD. The results for a presumably typical coding session, look something like this:

Notice that this developer spent a significant time doing test-last development (the red area), and only did refactoring after several cycles of Red-Green (or even Green-Green aka test-last).

So the conclusion?

Many or most of these purported TDD practitioners are not doing TDD, and it further, it did not hurt the quality of their code. Therefore, it’s not TDD that improves code quality, rather, as Fucci claims in the video it’s the granularity of the coding cycles.

We observed that the major benefit of doing Test-Driven Development, or the things that explain the perceived benefit of TDD, like better code quality as well as productivity, … is not the rigid, religious adherence to the Test-Driven Development cycle, but rather how fine-grained are the activities in the process? So the fact that each activity, such as writing code and writing tests, or the other way around, writing tests and code, and then refactoring, are kept within a short and consistent time interval.

That’s some pretty good insight.

The important thing isn’t the red/green/refactor cycle… rather, the important thing is working in short test/code or code/test cycles.

My experience would agree with this conclusion. I don’t strictly adhere to the red/green/refactor mantra, but I do pretty consistently work in short cycles of minutes or even seconds.