I am looking for some best practice strategies for unit testing code written for embedded system. By embedded system, I mean code such as device drivers, ISR handlers etc., stuff that are pretty close to the metal.
Most of the unit tests are not possible without testing it on the hardware with the aid of a ICE. Sometimes, the embedded unit also needs to be hooked up to other stimulus such as a mechanical switches, stepper motors and light bulbs. This usually occurs in a manual fashion, automation would be great but hard and expensive to achieve.
Update
I came across a C testing framework that seems to be quite successful in testing embedded projects. It uses the ideas of mocking hardware. Check out Unity, CMock, and possibly Ceedling.
Update 06Jul2016
Came across cmocka – seems to be more actively worked on.
Best Answer
I would abstract away from the hardware dependencies at the earliest possible step, and build the system on software emulation/test harnesses, enabling all sorts of test frameworks. Often my developement PC was used to test as much as 95% or more of the complete system. The cost of the extra overhead (another layer of abstraction) was easily won back by the cleaner code generated as a result of that abstraction.
The testing of the truely baremetal parts of an embedded system is usually a seperate application (Unit test?) that hammers the firmware well beyond what the applications can even hope to achieve. Automation can be done - at a cost, but is not typical.
Unless, that is, you have the budget to build a unit test hardware harness including full ICE. This is absolutly fine as generally the functional tests are small.