Keep tests separate from production, wire up a tiny runner, and mock hardware at the header boundary. Here’s the minimal, repeatable setup that works with CubeIDE/MDK/IAR or Make.
๐ Project anatomy (add, don’t tangle)
๐ In CubeIDE: right-click TDD → Resource Configurations → Exclude from Build… (all configs).
✅ Unity: tiny test + runner
Build a test target that compiles: unity/*.c, tests/*.c, and module(s) under test.
(Optionally -DUNIT_TEST for test-only code paths.)
๐ CMock: mock the hardware boundary
Run CMock over headers → emits mock_driver.* into /TDD/mocks. Compile tests against mocks, not real drivers.
๐งช Build wiring (Make-ish sketch)
In IDEs, make a Test build config that includes TDD/… and excludes hardware files you’re mocking.
⚡ Pro Tips
-
Keep tests fast & pure: no HAL clocks/ISR—mock them.
-
One behavior per test; readable names:
test_<unit>_<behavior>_<expectation>. -
Generate mocks from headers you own (stable API).
-
Gate test-only code with
#ifdef UNIT_TEST. -
Failures first: write the test, see it fail, make it pass, refactor.
๐ฏ Conclusion
Separate tests, add Unity runner, mock hardware with CMock—now your embedded code is testable without boards, fast, and refactor-friendly.
Written By: Musaab Taha
This article was improved with the assistance of AI.