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:
- The fact that the hardware interfaces on which the software depends make it hard to test the software outside the hardware.
- The lack of space within the hardware to run a unit test framework.
- 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.
Tags: agile, automation, development process, embedded, strategy, unit testing
