What are the best unit testing frameworks for embedded C and C++?

Unity (often with Ceedling and CMock) and CppUTest are the most common for C on microcontrollers; GoogleTest suits C++ code that also builds on the host. All of them test logic on the host, so pair them with a level that runs the real binary against the hardware.

What is the difference between firmware testing and software testing?

Software testing usually runs code on the machine it was built on. Firmware testing has to account for the hardware: registers, pins, buses, interrupts, timing and power. The same bug can pass on a laptop and fail on the board.

Can you test firmware without the hardware?

Yes, up to a point. Unit tests cover pure logic, and a board-level simulation runs the real binary against the board's wiring and parts. Analog accuracy, RF and electrical limits still need the physical board.

What should firmware tests cover first?

Boot and clock setup, every device answering on its bus, the power-up order, and the error paths: what the firmware does on a NACK, a timeout or a brown-out. These fail most often at bring-up.

How do you test firmware timing?

Measure it: record edges and bus transactions with timestamps and check them against the datasheet limits. On hardware that takes a logic analyser; in simulation every signal is recorded, so timing checks can run in CI.

Is firmware testing the same as hardware-in-the-loop testing?

No. Hardware-in-the-loop is one level of firmware testing, the one that uses the real board and a test rig. Unit tests and simulation come before it, field testing after.

Firmware testing: how to test embedded firmware, with or without the board

Adam Szefer · Co-founder & CTOOctober 22, 2026

Prev. Bloomberg · Gyfted. Systems and simulation infrastructure — the engine that runs your firmware against the circuit.

Firmware testing is how you find out whether code that compiles also works on the board it was written for. Most firmware bugs aren't logic errors. They are disagreements between the code and the hardware: a wrong pin, a bus address, a timing limit, a power-up order. This guide covers the levels of testing embedded teams use, what each one catches, and how to start before the hardware arrives.

What is firmware testing?

Firmware testing checks that the software running on a microcontroller does the right thing on its hardware: it boots, configures clocks and pins, talks to every chip on its buses, handles interrupts in time, survives power events and recovers from faults. Unlike application testing, the inputs are electrical (a GPIO edge, an I²C NACK, a sagging rail), and the code under test usually can't run on a laptop as it is.

The four levels of firmware testing

Unit tests run pure logic on the host with a framework such as Unity, CppUTest or GoogleTest; they are fast, but mock the hardware away. Simulation runs the real binary on a model of the MCU and, with a board-level model, of the parts around it. Hardware-in-the-loop runs on the real board, with a rig that feeds it signals and measures its outputs. Field and system testing puts finished devices in real conditions. Each level catches what the one before can't, and the cost and the wait grow at every step.

How to test firmware without hardware

Before boards exist, firmware is usually tested only with unit tests, so everything that depends on the schematic waits for bring-up. A board simulator closes that gap. It is built from the netlist and BOM, so the firmware sees the same pins, buses and addresses it will see on the real board, and a wiring or timing mistake fails the way it would on the bench. The guide to simulating firmware without hardware compares MCU emulators with board-level simulation.

Where developers test firmware for real-time systems

Real-time firmware is tested where its timing can be measured: on target hardware with a logic analyser or trace probe, on a HIL rig that checks response deadlines, and in simulation, where every edge is recorded in exact simulated time and a run repeats identically. Host unit tests can check the algorithm, but not whether an interrupt is serviced before the next one arrives.

Best tools for testing embedded firmware

Unit-test frameworks (Unity with Ceedling, CppUTest, GoogleTest) are fast and cheap and need no hardware knowledge. MCU emulators such as QEMU run the binary, but their peripherals are idealised and know nothing about your board. Board-level simulation runs the binary against the board's actual parts and wiring, and can be scripted in CI. HIL rigs and bench instruments give the physical truth, at the cost of hardware, fixtures and bench time. Most teams pair a fast host suite with one hardware-aware level.

Putting firmware tests in CI

The tests that pay off most are the ones that run on every commit. Host unit tests are easy to automate; hardware tests usually aren't, because boards are scarce and someone has to look after the rig. A simulated board runs headless, so board-level checks (this sensor answers at this address, this rail comes up before that one, this command toggles this pin) can gate every merge.

FAQ

What are the best unit testing frameworks for embedded C and C++?: Unity (often with Ceedling and CMock) and CppUTest are the most common for C on microcontrollers; GoogleTest suits C++ code that also builds on the host. All of them test logic on the host, so pair them with a level that runs the real binary against the hardware.
What is the difference between firmware testing and software testing?: Software testing usually runs code on the machine it was built on. Firmware testing has to account for the hardware: registers, pins, buses, interrupts, timing and power. The same bug can pass on a laptop and fail on the board.
Can you test firmware without the hardware?: Yes, up to a point. Unit tests cover pure logic, and a board-level simulation runs the real binary against the board's wiring and parts. Analog accuracy, RF and electrical limits still need the physical board.
What should firmware tests cover first?: Boot and clock setup, every device answering on its bus, the power-up order, and the error paths: what the firmware does on a NACK, a timeout or a brown-out. These fail most often at bring-up.
How do you test firmware timing?: Measure it: record edges and bus transactions with timestamps and check them against the datasheet limits. On hardware that takes a logic analyser; in simulation every signal is recorded, so timing checks can run in CI.
Is firmware testing the same as hardware-in-the-loop testing?: No. Hardware-in-the-loop is one level of firmware testing, the one that uses the real board and a test rig. Unit tests and simulation come before it, field testing after.

HardLabs

Send us your design. We'll send you a simulator.

We build a board simulator from your netlist, schematic, and BOM, run your real firmware against it, and fail CI when pinmux, buses, or timing contracts break.

A working simulator of your board, built from netlist, schematic, and BOM.
Peripheral models attached so your firmware can talk to the board.
A setup that runs your real firmware binary — no rewrite required.

Pilot details · App

Simulate firmware without hardware
Simulate firmware without a board: where QEMU’s idealized peripherals fall short, and how board-level models catch pinmux and bus bugs before fab.
Firmware testing services
Firmware testing services on a simulation of your real board. Send netlist, BOM and firmware; we build the board model, run your binary and report what broke.
What is HIL testing?
HIL testing explained: how a hardware-in-the-loop test system works, HIL vs SIL testing, HIL in automotive, and testing before the hardware exists.
Firmware-in-the-loop
Firmware-in-the-loop against your netlist — not stubs. Run unmodified .elf images on MCU simulation with board-aware I²C/SPI models and CI assertions.
HardLabs vs QEMU

HardLabsAll topics