wedsamuel1230/arduino-skills/hardware-tdd

Hardware TDD

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

1. Turn requirements into observable behavior and safety invariants.
2. Write host tests for pure C/C++ logic using fakes for time, serial, sensors,

and actuators. Keep hardware adapters thin.

1. Use Wokwi or another simulator only for peripherals and timing that its model

actually represents; record model limitations.

1. Run an exact-board compile and static checks with the selected toolchain.
2. Create a one-change target checklist: power-off continuity, controlled

power-up, input observation, output inhibit, reset/recovery, and logs.

1. Ask a physical gate for measurements, photos, or serial output. Do not infer

target success from a host test or compile log.

1. Record failures as evidence and keep the next test bounded.

Test matrix

Anti-rationalization

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 gate format from

embedded-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.