Testing is formwork, code is concrete

By Andrew Clifford

Test-driven development cuts costs and improves quality, but can be difficult to understand and justify. Thinking of testing as the formwork into which code concrete is poured can help you understand test-driven development and justify its adoption.

It comes as a bit of a shock to have to practise what you preach. For years I worked as an internal advisor to an IT department. But recently I've been working in a joint venture putting together some tools to support no-nonsense IT governance. I'm doing systems development for a change, not just advising on it.

For our medium-sized online system, I would have given advice like this:

• Design outside-in. Define the uses and outputs of the system, then work inwards to the internal design. This stops you building elegant-but-pointless systems.
• Integrate continually. Every time you have a new component, integrate it into the evolving system. This removes the huge integration effort later in the project, and highlights inconsistencies earlier, when they are cheaper to fix.
• Use test-driven development. Write tests for the system and see them fail before writing code.

The first two are self-evident. But when it came to putting my own time and money behind it, I wasn't so sure about test-driven development. Was it really worth it, or should I use the traditional "test later" approach?

I searched for a similar concept. The closest I could find was formwork. Formwork is the structure of wood or aluminium sheets into which concrete is poured.

This really helped me understand why test-driven development is so valuable, and how to go about it.

Formwork is what actually turns the architect's design into reality. Without it, the concrete would slop everywhere. You would have to spend ages checking that it met the specification. Then you would have to chip off the bits you don't want, and patch the bits that were missed. When time or money runs out, you would have to stop and make do with a low quality product. Very much like the traditional approach to testing.

If you can't build the formwork, you can't pour the concrete. The need to make everything testable forces good design. To test our system, we needed to separate the core functionality from the web pages. As well as making testing easier, this makes it much easier to change either the web pages or the core functionality without affecting the other.

The test-driven approach helps check that the design is complete. Our system had a licensing component which we had not thought through well. We discovered this when we couldn't write tests for other parts of the system that used it.

The analogy breaks down after a while. Although through time code gets more difficult to work with, unlike concrete it never sets. But all the more reason to have the reusable formwork of automated regression tests to stop it slopping everywhere when you change it.

There are many more aspects to test-driven development than I can cover here. But thinking of it like formwork has really helped me grasp the concept and put it into practice. And I'm producing some of the best quality code I ever have.

Subscription