program selection system

I’ve been told that “everyone knows” that code written TDD is simpler than code written otherwise. But is that really true? And how could we tell? And what would it really mean anyway? I’ve found a metric, intimately related to complexity, that correlates very well with whether or not code comes with automated unit tests. It also looks a lot as if it correlates somehow with the degree of TDD-ness applied. Come see it in action, learn how it works, and contribute to the on-going investigation!

An updated and improved version of this session from last year (also exhibited at Spa and XPDay).

In this session attendees will learn about these reuslts, see the tool and apply it to code, to see what clues about the TDD process and maybe how to do it better can be obtained.

The distribution of complexity as measured by McCabe’s metric, per method, in a range of open-source Java codebases seems to be goverened by a power-law (or at least, a power-law can be closely fit through it). The “shape” parameter of this distribution is observed to be 2 or more for code that comes with comprehensive suites of automated unti tests, and less than 2 for code that doesn’t. Being published with unit tests seems a reaonable proxy for having been written TDD: I don’t believe that anyone is writing code any old how then retrofitting such tests. Some people do believe that, and the topic is under active investigation.

Anecdotal evidence from poeple who have applied this metric on their own code suggests that refactoring exercises aimed at improving internal quality can be seen to drive the shape parameter to larger values. Code that we might think of as exemplary TDD code (eg the jMock framework) has a higher value of the shape parameter than code that might be imagied to have neen less rigorously TDD’d

No such pattern has been found when, for exmaple, the distribution of literal size for methods is modelled. Also, code that is of manifestly high quality can still have a low shape parameter if it was not TDD’d.

So, it looks a lot as if TDD does somehting to your design, and its something to do with preferring less complex methods over more complex ones. We will explore what that might be, and what it might mean. If this is anything to go by, it might just mean fewer defects, on average.