Embedded Linux and firmware tests can pass in Docker and still fail on real hardware.
That doesn't mean simulation is wrong, just that each layer of testing has its own job. Mocks let you test software decisions against an abstraction. Emulators cover the parts of a system that are easy to model. Hardware-in-the-loop is what tells you whether the board, firmware, boot flow, buses, power behavior, and peripherals all play nicely together.
Each of those abstractions has a known blind spot: USB attached to a developer laptop isn't deterministic, mocks replace real peripherals with assumptions about how they behave, and QEMU runs a model of the CPU rather than your actual board. Each is fine right up until the bug lives in the thing you abstracted away.
What Real Hardware Exposes
A basic HIL prototype usually has:
- Power control
- UART capture
- Flashing or netboot
- GPIO observation
- I2C, SPI, or peripheral UART interaction
That setup catches a class of bugs the earlier layers cannot: timing dependencies, boot-order sensitivity, electrical assumptions, peripheral quirks, recovery paths that never get exercised, and state leaking between runs.
Fast software tests should still run first. HIL is the layer that answers the question those tests cannot: does this build actually work on the hardware we ship?