If you’ve worked your way through to the end of the example then I expect that, like me, your first reaction was surprise that the process worked and that the solution turns out to be simple. My second reaction was to wonder if it would have just been easier to do a bit more analysis on the roman numeral rules up front and just code them.

The truth is … I don’t know what approach would be most efficient for the i2r() example. But I spend a lot of time in the company of TDD experts and they tell me that the i2r() example is a great way to demonstrate TDD, but it’s not a great example of TDD. The power of TDD really comes out when working on bigger problems.

A friend[1] reviewing this document commented,

“As for your conclusion…who knows if an initial analysis/design up front would have led you to the same elegant solution? Perhaps that isn’t the important point of TDD. When using TDD I always find that I am far more familiar, and hence able to talk about, the eccentricities in the domain that I’ve uncovered through TDD and much more open to incorporating future eccentricities as they are uncovered by myself or my customer. I’m already in the change frame of mind.”

One, other comment I received, from a friend, Doug Brophy:

… I found the following explicit column headers helpful when I first started:

So, in conclusion, I hope that this example has given you a feel for how TDD works, that TDD can work and that TDD is worth exploring further.

[1] I’d like to thank the huge number of people who have kindly provided feedback on this document. If you have further feedback then please email me on