Jacques Mattheij

Technology, Coding and Business

today I wrote some code

And I used to think that was all there was to it. Sure, I would test my code but typically that was limited to testing whether expected input produced expected output.

Since about a year I’ve become a convert in the school of testing. Test, test, test. Only after all the edge cases have been tried and code coverage is as high as I can get it without contortions I’ll say that code actually works.

It is still surprising to me how just testing at the interfaces of the code will bring faults to the surface with an uncanny lack of mercy. It’s not rare for a 5 line change that is ‘trivial’ to produce several test failures. And that’s when I think I know the code like my back pocket!

For a lark I’m going to take an old project that has been running for years without a hitch and I’m going to retro-actively add tests to the code. I’m really curious how many bugs and unexpected behaviors will turn up.

Typically software that has been in production for a long time takes on a ‘cast-in-concrete’ status. Don’t touch it and if it isn’t broken please don’t fix it. But that also precludes growth and any serious change or refactoring tends to result in a re-write rather than a re-use. And with re-writing and debugging being far more expensive than testing it is interesting to see that an old dog like me (which are renowned to be hard to teach new tricks to) can become so thoroughly convinced that I’ve been doing it wrong for many years.

So now I don’t just write code. I write a substantial chunk of code to go along with the code to put it through its paces, to confirm that it really does what I intend for it to do and to make sure that if stuff gets changed that I’ll be alerted to no longer being in spec. This has become second nature to me over the course of a year, but only after doing it wrong for several decades.

I no longer think it is good enough if there are no bugs found during production runs, I no longer believe in trivial changes being trivial. In that sense this last year has really been eye opening and I have good hope that in the long run this will tremendously increase my productivity. Even if in the short term it seemed as though my productivity took a hit (after all, writing code that tests stuff does not add any functionality to the program itself).

If you haven’t tested it, I guarantee that it doesn’t work.

So don’t just write code. Write tests too and watch your productivity slowly but steadily increase.

Testing > Debugging!