Unit content
Embedded testing and hardware-in-the-loop
Embedded software can be tested at several boundaries because some behavior is ordinary computation while other behavior depends on the physical target.
Logic that does not require registers or timing can often run as fast host-side automated tests. A driver interface can be replaced by a fake when the goal is to test application decisions independently of one board.
On-target tests execute on the real processor and toolchain, exposing assumptions about data widths, alignment, startup or target libraries that host tests can miss.
A hardware-in-the-loop (HIL) test connects the firmware to controlled external hardware or instruments that stimulate inputs and measure outputs. It can test behavior such as GPIO timing, serial communication or response to sensor-like signals while keeping the experiment repeatable.
Mocks cannot prove an electrical interface works, while hardware-only tests can be slow and difficult to diagnose. The useful boundary depends on the failure being protected against.
A strong embedded test strategy therefore keeps most deterministic logic cheap to test while reserving real hardware for properties that genuinely depend on the target and its physical interfaces.