Testing and code coverage

Quick Cap

Testing embedded software is harder than testing desktop applications because firmware interacts with hardware that is expensive to simulate and subject to real-time constraints. A solid embedded testing strategy uses unit tests (run on the host) for logic correctness, hardware-in-the-loop (HIL) tests for integration with real peripherals, static analysis for catching bugs without execution, and code coverage to verify that tests exercise the code paths that matter. Interviewers want to see that you understand the testing pyramid, can choose the right framework, and know how to automate it all in CI/CD.

Key Facts:

• Unity (pure C) and CppUTest (C/C++) are the most common embedded unit test frameworks; Google Test is used for C++ targets
• TDD (Test-Driven Development) works well for embedded: write the test, stub the HAL, implement the logic, pass the test
• HIL testing runs real firmware on real hardware with simulated stimulus -- catches timing and interrupt interaction bugs that unit tests miss
• Coverage metrics: statement coverage is the baseline; branch coverage catches untested decision paths; MC/DC is required by DO-178C and ISO 26262 ASIL D
• Static analysis tools (cppcheck, PC-lint, Coverity) and MISRA compliance checkers find defects without executing code
• CI/CD for embedded typically cross-compiles on the server, runs host-based unit tests, and optionally flashes a HIL board for integration tests

Deep Dive

Testing Pyramid for Embedded

/\
          /  \          System / HIL tests
         / HW \         Real hardware, real peripherals
        /------\         Slow, expensive, catches integration bugs
       /        \
      / Integr.  \       Integration tests
     /  (stubs)   \      Module boundaries, mock HAL
    /--------------\     Medium speed
   /                \
  /   Unit tests     \   Function-level, host-compiled
 /  (pure logic)      \  Fast, cheap, high coverage
/______________________\

The pyramid principle: write many fast unit tests at the base, fewer integration tests in the middle, and few HIL/system tests at the top. Unit tests give rapid feedback on logic errors. HIL tests are essential for catching the bugs that only appear when real hardware timing, interrupts, and peripheral behavior are involved.

Unit Testing Frameworks

A typical Unity test for an embedded ring buffer:

#include "unity.h"
#include "ring_buffer.h"

static ring_buf_t rb;
static uint8_t storage[16];

void setUp(void) {
    ring_buf_init(&rb, storage, sizeof(storage));
}

void test_push_pop_returns_same_value(void) {
    TEST_ASSERT_TRUE(ring_buf_push(&rb, 0xAB));
    uint8_t val;
    TEST_ASSERT_TRUE(ring_buf_pop(&rb, &val));
    TEST_ASSERT_EQUAL_HEX8(0xAB, val);
}

void test_pop_from_empty_returns_false(void) {
    uint8_t val;
    TEST_ASSERT_FALSE(ring_buf_pop(&rb, &val));
}

void test_full_buffer_rejects_push(void) {
    for (int i = 0; i < 16; i++)
        ring_buf_push(&rb, i);
    TEST_ASSERT_FALSE(ring_buf_push(&rb, 0xFF));
}

The key embedded testing pattern is HAL abstraction: separate hardware access into a thin HAL layer, then provide a mock or stub HAL for host-based tests. The business logic (state machines, protocol parsing, control algorithms) is tested against the mock HAL at full speed on the host.

TDD Workflow in Embedded

1. Red -- Write a failing test that describes the desired behavior.
2. Green -- Write the minimum code to pass the test.
3. Refactor -- Clean up duplication, improve naming, optimize.
4. Repeat -- Add the next test case.

TDD is especially valuable in embedded because it forces you to decouple logic from hardware early. Modules developed with TDD are inherently testable on the host, which means faster iteration and earlier bug detection compared to the traditional "write code, flash, debug on target" loop.

Hardware-in-the-Loop (HIL) Testing

HIL testing bridges the gap between host-based unit tests and full system deployment. A typical HIL setup:

+-----------+      UART/SPI/I2C      +--------+      GPIO/ADC/DAC      +-----------+
  |  Test PC  | <------------------->  | Target | <------------------->  | Stimulus  |
  | (pytest / |      (flash + log)     |  MCU   |      (sensors,        |  Hardware  |
  |  Robot FW)|                        |        |       actuators)      | (or sim)   |
  +-----------+                        +--------+                       +-----------+

The test PC flashes firmware onto the target MCU, sends stimulus commands, monitors outputs (GPIO toggles, protocol messages, ADC readings), and compares results against expected behavior. Popular frameworks for orchestrating HIL tests include pytest (with serial/JTAG plugins), Robot Framework, and custom scripts using pyOCD or OpenOCD.

HIL tests catch bugs that unit tests structurally cannot: interrupt timing races, DMA completion ordering, peripheral initialization sequencing, and clock-dependent edge cases.

Code Coverage: Statement vs Branch vs MC/DC

gcov + lcov is the standard open-source toolchain for C/C++ coverage. Compile with -fprofile-arcs -ftest-coverage, run tests, then generate an HTML report:

gcc -fprofile-arcs -ftest-coverage -o test_runner tests/*.c src/*.c
./test_runner
lcov --capture --directory . --output-file coverage.info
genhtml coverage.info --output-directory coverage_report

100% statement coverage does not mean the code is bug-free. A function with if (a && b) can achieve 100% statement coverage by testing only the true path. Branch coverage requires testing both outcomes. MC/DC goes further: it requires showing that changing each individual condition (a alone, b alone) independently changes the decision outcome.

Static Analysis

Static analysis catches null pointer dereferences, buffer overflows, uninitialized variables, dead code, and type conversion issues -- all without running the code. In safety-critical domains (automotive, medical, avionics), MISRA compliance is often mandatory.

CI/CD Pipeline for Embedded

commit --> [build] --> [static analysis] --> [unit tests] --> [coverage check] --> [HIL tests] --> [artifact]
              |               |                    |                 |                   |
              v               v                    v                 v                   v
           cross-compile   cppcheck +           Unity /           lcov report       flash target,
           (arm-gcc)       MISRA check         CppUTest           >= 80% branch     run integration
                                                on host                              on real HW

Key CI/CD practices for embedded:

• Cross-compile on every commit to catch compile errors immediately, even without hardware
• Run host-based unit tests as the primary quality gate -- they are fast and deterministic
• Enforce coverage thresholds -- fail the pipeline if branch coverage drops below the target
• Static analysis as a gate -- new warnings block the merge
• HIL tests on nightly or per-PR -- slower but catch real hardware integration issues
• Archive build artifacts (ELF, BIN, MAP files) for traceability

Debugging Story: The Timing Bug HIL Caught

A motor control module passed all 200+ unit tests with 92% branch coverage. In production, the motor occasionally stalled during direction reversal. Unit tests could not reproduce the issue because they ran the control loop synchronously -- the mock timer always returned perfectly spaced intervals.

The HIL test rig used a real motor driver board and a variable-frequency PWM source. When the test script commanded a rapid forward-reverse-forward sequence, the real ISR latency occasionally caused two consecutive timer interrupts to fall within the same control loop iteration, doubling the torque command and triggering the overcurrent protection. The fix was to add a delta-time clamp in the control loop. The key lesson: unit tests verify logic; HIL tests verify timing and integration. Both are necessary, and neither alone is sufficient.

Interview Focus

Classic Interview Questions

Q1: "How do you unit-test embedded C code that directly accesses hardware registers?"

Model Answer Starter: "I abstract hardware access behind a thin HAL layer -- for example, hal_gpio_write(pin, value) instead of writing to a register directly. For unit tests, I provide a mock HAL implementation that records calls and returns configurable values. This lets me test the business logic (state machines, protocol parsers, control algorithms) on the host at full speed. Tools like CMock can auto-generate mocks from header files. The real HAL is compiled only for the target build."

Q2: "What is the difference between statement coverage, branch coverage, and MC/DC?"

Model Answer Starter: "Statement coverage measures the percentage of executable lines that were run -- it is the weakest metric. Branch coverage requires that every decision point (if/else, switch) has been evaluated to both true and false outcomes, which catches untested error paths. MC/DC goes further: for compound conditions like if (a && b), it requires showing that changing each condition independently affects the decision outcome. MC/DC is required by DO-178C Level A for avionics and ISO 26262 ASIL D for automotive."

Q3: "How would you set up a CI/CD pipeline for an embedded project?"

Model Answer Starter: "The pipeline starts with a cross-compilation step using the target toolchain (arm-none-eabi-gcc) to catch compile errors. Next, I run static analysis (cppcheck or PC-lint) and fail the build on new warnings. Then host-based unit tests run with coverage reporting via gcov/lcov, with a branch coverage threshold as a quality gate. For nightly builds or before release, I trigger HIL tests that flash the firmware onto a test board and run integration scenarios. All build artifacts are archived for traceability."

Q4: "When would you use HIL testing instead of unit testing?"

Model Answer Starter: "HIL testing is essential when the behavior under test depends on real hardware timing, interrupt interactions, or peripheral sequencing that cannot be faithfully mocked. Examples include verifying ADC sampling rates, testing DMA completion callbacks under ISR load, validating motor control loop timing, and testing communication protocol recovery under noise. Unit tests remain the first line of defense for pure logic, but HIL tests catch the integration bugs that only manifest with real silicon."

Q5: "What MISRA C rules do you consider most important, and why?"

Model Answer Starter: "The rules I focus on first are: no dynamic memory allocation after initialization (Rule 21.3) to prevent fragmentation and non-deterministic timing; no recursion (Rule 17.2) to ensure stack usage is statically analyzable; all if-else-if chains must end with an else clause (Rule 15.7) to force explicit handling of unexpected cases; and no implicit type conversions that could cause data loss (Rules 10.x). These rules eliminate entire classes of bugs common in embedded systems: stack overflows from recursion, heap fragmentation, and silent data corruption from integer promotion."

Trap Alerts

• Don't say: "We do not need unit tests because we test on the hardware" -- unit tests catch logic bugs orders of magnitude faster than on-target debugging
• Don't forget: The difference between coverage metrics -- interviewers will probe whether you understand why statement coverage alone is insufficient
• Don't ignore: Static analysis as a complement to testing -- it catches bugs that tests may never exercise (dead code paths, rare error conditions)

Follow-up Questions

• "How do you handle testing of interrupt-driven code in unit tests?"
• "What is mutation testing and how does it improve confidence in your test suite?"
• "How do you test firmware update (OTA) logic without bricking the device?"
• "Describe how you would test a state machine with 20+ states and transitions."

Practice

Real-World Tie-In

Medical Infusion Pump Certification -- A medical device team needed IEC 62304 Class C compliance, which required demonstrating MC/DC coverage on all safety-critical modules. They used CppUTest on the host for logic testing, gcov with a custom MC/DC post-processor for coverage analysis, and a HIL rig with calibrated syringe actuators for flow-rate validation. The CI pipeline rejected any commit that reduced branch coverage below 85% or introduced MISRA violations. The disciplined approach cut certification audit findings by 70% compared to their previous product.

Consumer IoT Hub Regression Suite -- An IoT hub team experienced a pattern of "fix one protocol, break another" across their Zigbee, BLE, and Wi-Fi stacks. They invested in a comprehensive Unity-based test suite with 1,400 tests covering packet parsing, state machines, and error recovery. A nightly HIL run exercised real radio modules in an RF-shielded enclosure. After six months, the regression rate dropped from 3-4 regressions per sprint to near zero, and developer confidence in refactoring increased dramatically.