embedded software boot camp

Thoughts on the optimal time to test code

Friday, June 6th, 2008 by Nigel Jones

Today I’d like to take on one of the sacred cows of the embedded industry, namely the temporal relationship between coding and testing of the aforementioned code. The conventional wisdom seems to be as follows.

“Write a small piece of code. As soon as possible test the code. Repeat until the task is complete”

I know for many of you, me merely having the temerity to suggest this might be sub-optimal will put me firmly into the category of hopeless heretic. Well, before you write me off as a lunatic, let me tell you about an alternative approach, how I stumbled upon it and why I think it has much to commend it.

Being in the consulting business I’m typically working on multiple projects at once. Often a given project will be put on hold for any number of reasons which aren’t germane to this post. As a result, it’s not uncommon for me to write some code, compile it and then not touch it again for several months. I then find myself in the position of having to test / debug code that I wrote months ago. Having now done this many times, I’ve come to the conclusion that rather than this being a problem, it is instead the optimal temporal relationship between coding and testing.

How can this be you ask? Surely after a multi-month hiatus, the code is no longer fresh in your mind and so it must make it that much more difficult to test and debug? Well the answer is of course yes – the code is no longer fresh in my mind, and yes it does make it a little harder to test and debug in the short term. In my emphasis lies the point of my argument.

Why do we write code? Most people would claim we write code in order to make a functional product. I disagree with this assertion. I think we write code so that people coming after us can understand it and modify it. This rather strange claim is based upon those studies that show that companies spend far more money maintaining code than they do writing it. Thus the smart way to write code is to do so in a manner that gives preeminent importance to the long term maintenance of that code. So how does one do this? Well that’s a topic for another post. What I can tell you, is that having to test and debug code that you wrote several months ago is a terrific way for the developer of the code to see the code as someone who’ll be maintaining it will see it. You’ll see the inadequate or plain wrong comments. You’ll see the copy and paste errors. You’ll see where you got tired and took a short cut, and you’ll see those stupid mistakes caused by the telephone ringing at the wrong time.

Indeed because you don’t expect the code to work (after all it’s never been tested) I find you cast a very jaundiced eye over the code – and in the process find a plethora of the mistakes that one typically finds by sitting in front of a debugger. Maybe it’s just me, but I’d rather find bugs via code inspection than by fighting the debug environments common to most embedded systems.

So in a nutshell, I think the optimal way to write and test code is as follows:

1. Write the code. Make sure it compiles and is Lint free.
2. Wait a few months.
3. Reread the code looking for the usual suspects of bad / wrong comments, copy and paste errors, sloppy coding etc.
4. Test it.

The person that maintains your code (quite likely a future version of you) will thank you for doing it this way.


Leave a Reply