Use the existing project test framework for software behavior and a hardware check when the requirement depends on the target, timing, power, or an electrical interface.
Choose the test
- A host test checks parsing, state transitions, and other isolated logic.
- A target build checks compilation and linking for the selected configuration.
- A flash-and-observe check verifies startup or a runtime marker.
- An instrument capture checks protocol traffic, timing, voltage, or current.
Record the test command and expected result in EMBEDDER.md.
Add a regression test
Keep the test tied to the failure or requirement. Use static analysis for additional checks when the analyzer is configured.
Add a board smoke test
Identify the board, port or probe, and power setup. A missing result is not a pass, even when programming succeeded.
Save a hardware script
Ask Embedder to create a script under .embedder/hardware/ with setup, bounded measurement, pass criteria, and cleanup.
Run it from chat, the VS Code Run Hardware Script action, or a terminal:
Complete required setup interactively before using the command unattended. Use profiles for per-bench ports or parameters. See Hardware scripts.
Add instrument evidence
Give channel assignments, sample rate, duration, trigger, and tolerance:
Use Debug mode for GDB state inspection and bounded J-Trace captures. Ordinary instrument scripts are also available in Act mode.
Run from automation
Use the CLI script runner in your test workflow or request repository checks through GitHub and Slack automation. The host must have the required tools and hardware.
A bounded /loop cannot run builds, flash targets, or start live captures. Use a script for a soak test or repeated hardware sequence.
Review failures
Keep the command, firmware artifact, target, observed output, and failed condition. Fix the setup or implementation, then repeat the same check. Report skipped or unavailable tests explicitly. Last modified on September 12, 2026
