Build the test ladder before claiming a feature is complete. Pure behavior can often be tested off-target; voltage, pin mux, timing under load, and physical assembly still require target evidence.
Intake
Record exact board/revision, framework/toolchain, hardware invariants, safety inhibits, simulator model, available instruments, test fixtures, and the proof stage required by the user.
Process
- Turn requirements into observable behavior and safety invariants.
- Write host tests for pure C/C++ logic using fakes for time, serial, sensors, and actuators. Keep hardware adapters thin.
- Use Wokwi or another simulator only for peripherals and timing that its model actually represents; record model limitations.
- Run an exact-board compile and static checks with the selected toolchain.
- Create a one-change target checklist: power-off continuity, controlled power-up, input observation, output inhibit, reset/recovery, and logs.
- Ask a physical gate for measurements, photos, or serial output. Do not infer target success from a host test or compile log.
- Record failures as evidence and keep the next test bounded.
Test matrix
| Layer | Example | Proves | Does not prove |
|---|---|---|---|
| Host | debounce/state/packet parser | deterministic logic | pin voltage or wiring |
| Simulation | modeled sensor/LED/UART | modeled interactions | regulator, clone, EMI, thermal behavior |
| Build | exact FQBN/environment | source and dependency compile | upload or behavior |
| Target | serial, meter, scope, photo | observed hardware behavior | field reliability unless loaded |
| System | integrated load/failure case | requirement under scenario | future deployment safety |
Anti-rationalization
| Shortcut | Response |
|---|---|
| "The unit test passed." | Keep all physical and system stages open. |
| "Wokwi matches the board." | List what the model omits and verify those items on hardware. |
| "The sketch compiled." | Require upload identity and target observations separately. |
| "The photo proves it works." | Require board identity, measurement context, and observed result. |
| "Mark it done and test later." | Keep the loop item blocked or needs-review until evidence exists. |
Verification
- Every requirement maps to a test, proof stage, and artifact path.
- Host/simulation/build/target/system results are labeled separately.
- Physical-only steps emit the concrete
Physical gateformat fromembedded-project-loop. - Failed and unverified cases remain visible in the report.
Shared output contract
Use the shared Arduino skill contract: state assumptions, required tools and versions, implementation steps, tests/evidence by proof stage, known limitations, and recovery/security notes.