The idea of unit testing has been around for many years. "Test early, test often" is a mantra that concerns unit testing as well. However, in practice, not many software projects have the luxury of building and maintaining a decent and up-to-date unit test suite. This may change, especially for embedded systems, as the demand for delivering quality software continues to grow. International standards such as IEC-61508, ISO-26262, and DO-178B require module testing for a given functional safety level. Unit testing at the module level helps to achieve this requirement. Yet, even if functional safety is not a concern, the cost of a recall—both in terms of direct expenses and in lost credibility—justifies spending a little more time and effort to ensure that our released software does not cause any unpleasant surprises.

Nevertheless, testing embedded system software presents a unique challenge. Since the software is being developed on a different platform than the one it will eventually run on, you cannot readily run a test program in the actual deployment environment, as is possible with desktop programs. There are several explanations for this disconnect. Engineers may not yet have target hardware, hardware may cost too much to give software developers access to it, the full environment may be difficult to replicate in a development shop, and so forth.

This article provides an overview of how unit testing can help developers of embedded systems software address this challenge. In a nutshell, it recommends leveraging stubbing to perform a significant amount of testing from the host environment or on a simulator. This allows you to start verifying code as soon as it is completed—even if the target hardware is not yet built or available for testing. As a result, the majority of the problems with the application logic can be exposed early—when error detection and remediation is easiest and fastest—and target testing can focus on verifying the interface between the hardware and the software.