Skip to content
How do you unit test firmware? We test almost nothing on host
question1 min read130 viewsSep 27, 2026

How do you unit test firmware? We test almost nothing on host

Diego Ramírez@diego_firmware

September 27, 2026 · 1 min read

#1 in Bare Metal

130 views3 comments

Honest question. In my team all the testing is on the target hardware: flash, run, look at the logs and the scope. We have some integration tests on a HIL bench but zero unit tests. When I propose unit tests, the people say is impossible because the code touch registers everywhere.

Is a codebase of around 60k lines of C, STM32, FreeRTOS. The drivers call the HAL directly from the application logic in many places.

How you started? Which framework? And how do you convince the team that is worth it? I have 8 years working in embedded and I am a bit embarrassed to ask this, but better ask than keep pretending.

Accepted answer

Siobhan O'Rourke#2 in Bare Metal1 like

not an embedded person but ive helped a firmware team with exactly this, so here goes - dont start with the drivers. start with the pure logic thats tangled up with them: state machines, parsers, protocol framing, calculations. pull those into files with no HAL includes and test them on the host with plain gcc. that team used Unity + CMock with Ceedling tying it together and it was grand - for the rest, put a thin interface between app logic and the HAL (a struct of function pointers, or just your own header) and swap in fakes in the tests - run the host tests in CI on every push. takes seconds. the HIL bench stays for what its good at - convince people with a bug. next nasty thing found on target, write the host test that reproduces it first and show how fast it runs and theres nothing embarrassing about asking. the embarrassing thing is 60k lines and nobody asking

View in the thread

#embedded#testing#firmware#c

Written by

Diego Ramírez

Firmware engineer at automotive supplier in Guadalajara. C, FreeRTOS, CAN bus, oscilloscopes. Mechanical keyboard collector (too many).

View profile

Get the best of #bare_metal weekly

One email each Monday with the most useful posts. No spam; unsubscribe in one click.

Comments

3

Sign in to join the conversation.

Sign in to comment

Accepted answer

Siobhan O'Rourke@siobhan_tests#2 in Bare Metal
not an embedded person but ive helped a firmware team with exactly this, so here goes - dont start with the drivers. start with the pure logic thats tangled up with them: state machines, parsers, protocol framing, calculations. pull those into files with no HAL includes and test them on the host with plain gcc. that team used Unity + CMock with Ceedling tying it together and it was grand - for the rest, put a thin interface between app logic and the HAL (a struct of function pointers, or just your own header) and swap in fakes in the tests - run the host tests in CI on every push. takes seconds. the HIL bench stays for what its good at - convince people with a bug. next nasty thing found on target, write the host test that reproduces it first and show how fast it runs and theres nothing embarrassing about asking. the embarrassing thing is 60k lines and nobody asking
1 net votes
Diego Ramírez@diego_firmware#1 in Bare Metal
This is gold, thank you. Start from the parsers is perfect, we have a CAN protocol parser that is 100% logic and we test it by sending frames by hand with a tool. Starting there next sprint
0 net votes
Tomasz Kowalski@tomasz_k#3 in Bare Metal
Same advice works for COBOL modernisation by the way. Find pure logic, isolate, test. Hardware or mainframe, legacy is legacy.
2 net votes