Embedded testing

The engineering objective

Combine component tests with hardware-backed integration checks.

The work starts from software interfaces, boards, test points and requirement coverage. The team should identify the authoritative revision of each input and record any assumptions needed to proceed. This prevents a later result from being interpreted against a different specification or configuration.

What needs technical attention

Host-side unit tests need complementary target tests for hardware-dependent behaviour.

The review centres on test isolation, reproducibility, hardware variation and coverage gaps. Each finding should identify the input revision, observed behaviour and supporting evidence. Distinguish a confirmed defect from a configuration issue, an unsupported case or an open engineering question before deciding how to resolve it.

How the work is reviewed

The practical sequence is: test components; exercise peripherals; inject errors; run integrated regressions. Intermediate reviews allow the client to resolve decisions while changes are still manageable. If an input changes, identify the affected activities and repeat the checks that depend on it.

The expected package comprises tests, harness configuration and regression evidence. Acceptance criteria should specify what the receiving team needs to reproduce, inspect or integrate these artifacts. Include known limitations and outstanding actions in that package, rather than assuming that delivery of a file implies acceptance.

Design for transitions, concurrency and recovery

Embedded behaviour is shaped by the target hardware as well as application code. Keep the processor, board revision, memory map, boot flow and peripheral configuration visible in the project baseline. Define ownership of buffers and shared state across tasks, interrupts and DMA. Specify whether an API can block, which context may call it and how errors are reported to its caller.

Testing should follow the device lifecycle: startup, configuration, normal work, overload, low-power transitions, update and recovery. Host-side tests are valuable for deterministic logic, while target tests are needed for hardware timing and peripheral behaviour. Record which environment produced each result. A passing simulated test should not be presented as a measurement from the physical board.

Observe resource use under realistic contention, including stack and heap peaks, interrupt latency, queue growth and deadline misses. Inject failures where the product must recover: a disconnected peripheral, failed initialisation, timeout or interrupted update. Release notes should state the compatible hardware and configuration, how the image was built and how a previous known-good state can be restored when the product’s update design supports it.

An illustrative review scenario

A peripheral times out while an application task is being stopped. Check that callbacks cannot access released memory, locks are released and a later restart can initialise the device cleanly. Keep a repeatable fault-injection test alongside the normal transfer test. The exact sequence depends on the target platform and is agreed during implementation.

Separate host checks from target behaviour

Organise tests by what they can actually demonstrate. Host-based unit tests can exercise isolated logic quickly, while peripheral timing, interrupt behaviour and power-state transitions may require a target board. Record the boundary between these environments. A passing mock-based test does not establish that a real sensor, controller or transport behaves the same way under load.

For target runs, preserve the board revision, build configuration, flashing method and diagnostic connection. Use a known starting state before each scenario and capture the output needed to distinguish a test failure from a lost serial connection or fixture fault. When tests run automatically, make timeouts and recovery behaviour explicit so a stalled device cannot be mistaken for successful completion.

Review the test matrix against product risks. Include the supported configurations, expected results, known exclusions and the reason for each exclusion. A release summary should distinguish executed, failed, skipped and blocked tests, with links to reproducible evidence. This makes it possible for the receiving team to assess the remaining uncertainty and decide which checks must run again after a firmware, board or dependency change.