Climbing the code face

By Andrew Clifford

Testing is not something that we do because we are strong at development. It is something we do because we know that we are weak.

Over the past few weeks I have been working hard on a new version of our Metrici Advisor product. Some days the work goes well. Some days, not so well. Last week it was very heavy going indeed - I had been working long hours and was feeling rather unwell.

I always write tests as I code, and so most of my time is spent swapping between the real code and test code. This was getting very hard and frustrating. I was finding errors in code I had written previously. I kept losing my place in the code and the tests, and getting lost in the twisty bits. And worst of all, the tests kept failing, and it was taking a long time to get a clean run through.

But then I realised something that made me cheer up. By testing as I code, I can overcome the difficulties that I have with development.

If I was infallible, then all my earlier design decisions would be perfect. I would not lose my place in the code. I would not need to write tests, but if I did I would always pass them first time. If I was feeling overworked and under the weather, it would not make any difference to my work.

But I am far from infallible. I get things wrong all the time, and have to rework the code frequently. I mistype things, and put errors in as I work on the code. I have bad days, and some days I can not seem to remember how the code works at all. Sometimes I spend hours wondering why my code does not work, only to find a silly error in my test data.

But the thing that made me cheer up is realising that by writing tests as I code, I can make progress despite these shortcomings. I do not test because I am some sort of super-guru of development who writes beautiful tests to prove how clever I am, I test because I am an all-too-fallible human who stumbles from error to error. And yet, despite these disabilities, a process of testing as I code lets me deliver high quality code to very ambitious deadlines.

Development is like climbing a mountain. When you climb, gravity is always against you, and there is a constant danger of falling. However good you are, you have to constantly insure against danger with ropes and pitons and cams and other equipment. But by accepting the danger and the constant possibility of error, and doing something about it, you can literally climb mountains.

The internals of our system, like most large systems, is horrifically complicated, much more complicated than the most gifted of developers could deliver unaided. But by recognising our shortcomings, and adopting processes that overcome our weaknesses, we can deliver it. By accepting our weakness, we can scale the mountains of development.

Subscription