
Ask HN: How do you test your embedded systems? - shandor
In the wake of James Coplien&#x27;s &quot;Why most unit testing is a waste&quot; 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.<p>Mainly, I&#x27;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.<p>However, that doesn&#x27;t (necessarily) mean that there are no tests at all. But it&#x27;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.<p>Do you use unit tests at all to verify embedded systems? Or is it system-level tests all the way?
======
boznz
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.

------
AnimalMuppet
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.

