qa-embedded
Embedded C/C++ testing: GoogleTest on ARM, Unity and Ceedling with CMock mocks, QEMU system emulation, gcov coverage, and hardware-in-the-loop. An authoring agent (embedded-test-author) detects the framework and execution path, scaffolds the harness when none exists, and writes one unit test per spec.
/plugin install qa-embedded@testland-qaFirst time? Add the marketplace with /plugin marketplace add testland/qa
- Category
- Functional testing
- Version
v1.4.3- Contents
- 6 skills · 1 agent
- Part of
- qa-role-mobile-desktop
Skills6
ceedling-build-runnerUse when a C project wants Unity, CMock and CException run by one build command, or CMock mocks need writing or reading: Ceedling project scaffolding, project.yml, test tasks, JUnit XML, gcov coverage, host vs cross builds and CI.skillembedded-coverage-strategy-referenceUse when deciding what code coverage level embedded C/C++ needs (statement, branch, MC/DC) and wiring gcov or llvm-cov into the build: host vs QEMU instrumentation, MISRA-C and DO-178C expectations by safety level, and report formats.skillgoogletest-embedded-armUse when embedded C++ (C++17 or later) on ARM needs unit tests with GoogleTest: TEST, TEST_F and parameterized tests, EXPECT vs ASSERT, fixtures, GoogleMock, cross-compiling with arm-none-eabi-g++, running on host or QEMU and XML output for CI.skillhardware-in-loop-referenceUse when scoping an embedded hardware-in-the-loop (HIL) rig or reading an automotive, aerospace or industrial HIL report: MIL, SIL, PIL and HIL stages, NI, dSPACE, Vector and Speedgoat stacks, CAN, LIN, FlexRay and Ethernet emulation, fault injection and ISO 26262, DO-178C and IEC 61508 evidence.skillqemu-system-test-runnerUse when embedded tests must run on a virtual MCU or SoC instead of the host or real hardware, for correct endianness, alignment and interrupts: qemu-system-arm, aarch64 and riscv32 machine and CPU flags, loading ELF binaries, semihosting exit codes, GDB and QMP, and CI.skillunity-test-framework-cUse whenever pure C code for 8-bit MCUs, Cortex-M or embedded Linux needs unit tests with ThrowTheSwitch Unity (not the Unity game engine): TEST_ASSERT families, setUp and tearDown, RUN_TEST, the test runner generator, config defines and CI via Ceedling JUnit XML.skill
Agents1
About qa-embedded
Embedded C/C++ testing: GoogleTest on ARM, ThrowTheSwitch Unity-C and Ceedling with CMock mocks, gcov coverage, QEMU system emulation
Choosing a framework
Read down the "Signal" column and stop at the first row that matches your project - never infer from a README or folder name alone:
| Signal in project root | Framework | Execution path | Start with |
|---|---|---|---|
Top-level Ceedling project.yml | Unity + Ceedling (existing stack) | host build; add QEMU if the build cross-compiles | ceedling-build-runner |
CMakeLists.txt with find_package(GTest) or a gtest_main link target | GoogleTest | host build + QEMU cross-compile under arm-none-eabi-g++ | googletest-embedded-arm |
Only *.c / *.h files, no harness yet | Unity + Ceedling (canonical ThrowTheSwitch setup; Ceedling documents no C++ support) | host build (fast loop) + QEMU for arch sanity | ceedling-build-runner |
Any *.cpp / *.cc / *.cxx (incl. mixed C/C++ - a C++ toolchain compiles both) | GoogleTest | host build + QEMU when cross-compiling | googletest-embedded-arm |
Ultra-low-RAM target confirmed by -mcpu=cortex-m0 / cortex-m0plus (8-16 KB) | Unity standalone (no Ceedling; GoogleTest's heap requirement precludes it) | host build + optional QEMU | unity-test-framework-c |
Execution-path tie-breakers: no cross-compile toolchain in the build file → host build only; arm-none-eabi-* detected with no physical board → host + QEMU (endianness / alignment / interrupt-vector sanity per qemu-system-test-runner); physical board access confirmed → host + QEMU + on-target, with the coverage artefact from the on-target build per embedded-coverage-strategy-reference. A safety standard (DO-178C, ISO 26262, IEC 62304, MISRA-C) sets the minimum structural-coverage level - see the same coverage skill.