Ask HN: How do you test your embedded systems?

3 points by shandor ↗ HN
In the wake of James Coplien's "Why most unit testing is a waste" getting posted once again, I once more started to wonder if some of its theses fit better to some niches in software industry than others.

Mainly, I've been working close to ten years with more or less embedded devices, and the amount of unit testing your usual embedded shop has would make most devs from other walks of the industry faint.

However, that doesn't (necessarily) mean that there are no tests at all. But it's much more common to come across tests that test a whole part of the system end-to-end, like testing that your I2C commands are actually having the desired effect on the other end, or that your IoT node sends sensible measurements to the MQTT channel it should.

Do you use unit tests at all to verify embedded systems? Or is it system-level tests all the way?

2 comments

[ 0.28 ms ] story [ 13.0 ms ] thread
Stuff that directly touches the hardware is hard to unit test. But embedded systems have a lot of timing and sequencing stuff that can be unit tested. I unit test that fairly thoroughly.

And it's amazing some of the things unit tests have turned up for me. Timing errors. Race conditions. Calling a (pure) virtual function in the destructor of the base class. Semaphore deadlocks.

Pulling a single code unit out to test is fine so long as interrupts and other race conditions are not involved, but you must do end-to-end system tests regardless and with extremes of voltage and temperature, corrupted IO etc. It's also good to also test your device without watchdog timers, BOR, stack overflow resets enabled to catch anything that will normally fix itself.

By the way I recommend all the BOR/Watchdog timers and bit error/stack overflow errors to POR the chip if it has the option, I still see commercial controllers and devices locking up and needing a manual power off reset, really unprofessional, so totally enable all these if your micro has them.