Test-Driven Development for Embedded Software

Recently I had the pleasure of presenting my two day course on developer unit testing at Sioux Systems in Holland. Sioux works with a lot of clients who build software embedded in hardware devices (like microscopes and in-car GPS units.) I also presented to a larger audience (190 signed up but there was only room for about 120) on the topic “Test Patterns: The road to effective test automation: Hot or Not?”. Several of the participants in the course and the Hot or Not presentation asked “How practical is it to do TDD on embedded software?” and expressed doubts about the practicality of it. The reservations seemed to be related to a few key areas:

1. The fact that the hardware interfaces on which the software depends make it hard to test the software outside the hardware.
2. The lack of space within the hardware to run a unit test framework.
3. Issues around timing and multi-threading.

While these are all good points, none of them is actually a contra-indication for automated unit testing and TDD. We have well-established techniques for decoupling our logic from its dependencies using Test Doubles (stubs, mocks, spies, etc.) The lack of space on the hardware is exactly why we should be considering debugging the software outsid of the hardware. And issues around timing and multi-threading are not unique to embedded software. In fact, these should encourage us to do more unit testing in which we can properly control the timing.

The general principle could best be summarized as “Avoiding DOH!” (I would love to claim that I made up this great term but I first saw it on James Grenning’s blog .) DOH stands for Debugging On the Hardware except on The Simpsons, where it is what Homer Simpson exclaims after doing something stupid. Now this is a particularly fitting cultural reference because that is usually exactly how we feel after we have spent many minutes or hours debugging some stupid little mistake, especially when we are doing it in a difficult to use environment (like “On the Hardware”!) The true value of TDD is to avoid these DOH moments by Debugging In Simulated Environment (DISE). Once we have eliminated all the stupid little programming errors we always make, then we can go on to testing the software On Hardware.

In a future post I’ll go into more detail about these thoughts.

Welcome to My Weblog

I’ve been meaning to start blogging for quite a while now but just haven’t gotten “a round tuit”. I have lots of excuses including preparing for quite a few conferences as part of my launch as an independent consultant. For those of you who know me as Chief Scientist of ClearStream Consulting in Calgary, Alberta. ClearStream is no longer. Unfortunately, the founder Denis Clelland died in April 2006 and the company hasn’t been the same since. This spring his widow Carol decided to cease operations. All the employees of the company were laid off and have now gone independent.

Being layed off is both a blessing and a curse. The curse is that one doesn’t know where one’s next pay cheque will come from. The blessing is that it opens doors to a range of new opportunities. I’m hoping that this new blog will help open those doors. To that end I’ll be posting my most recent thoughts on the whole area of automated testing as we apply it on agile projects. This will include both traditional unit test automation as part of Test-Driven Development and automated acceptance/customer/functional testing. I also expect to blog a fair bit about test automation strategy including how the unit testing, acceptance testing and other forms of automated testing complement each other.