Test Lifecycle

Last updated on May 21, 2026

On TofuPilot, hardware tests follow a continuous cycle of four stages: author, deploy, run, analyze.

Author

A procedure declares the test logic TofuPilot executes. Three formats are supported:

  • Supported framework: Run OpenHTF, Pytest, or Robot suites natively.
  • TofuPilot Framework: YAML + Python with phases, plugs, operator UI, and parallel execution built in.
  • Custom test code: Drive your own test loop and upload runs through a typed SDK (Python, C#, Rust, C++, MATLAB) or the REST API.

Procedures are edited in your code editor, and supported frameworks can be run in the CLI to test before deploying.

Deploy

Two deployment paths are supported:

  • Git-backed for the TofuPilot Framework and supported frameworks: Every push to a connected Git repo creates a Deployment that rolls out to every Station bound to the branch. Supported providers:
  • Custom test code: Bring your existing deployment pipeline. Authenticate the bench with a station API key so runs land under the right station.

Stations reconcile their checkout between runs, so operators never see a half-applied update.

Run

Execution

Every run walks the same sequence:

  1. Identify the unit: Resolve the serial against the unit configuration.
  2. Initialize plugs: Each Plug starts in its own subprocess. A failure aborts the run.
  3. Setup phases: Calibration and warm-up. A failure aborts the run.
  4. Main phases: Parallel where independent, serialized by depends_on, bounded by per-phase timeouts.
  5. Teardown phases: Always run. Power down, release fixtures, dispose resources.

Supported framework connectors cover a subset of this sequence. See the framework feature matrix for which framework supports what.

Operator UI

A phase can pause and prompt an operator for input (visual inspection, manual action) or stream live values back to the dashboard. Inputs block until submitted, displays update in real time, and the same component tree renders in the Terminal UI, Remote UI, or Kiosk UI depending on the station setup.

Outcome

  • Resolve outcome: Worst phase wins: ERRORABORTEDTIMEOUTFAILPASS.
  • Upload: Send the payload (procedure, unit, phases, measurements, logs, attachments) through the REST API. Stations queue offline and drain on reconnect with the original timestamp.

Analyze

Every uploaded run feeds the dashboard. Use these views to diagnose production issues:

ViewUse for
YieldSpot FPY, SPY, TPY, LPY trends across procedures, stations, batches, revisions.
Failure analysisRank phases by failure count and duration to find weak steps.
Process controlWatch Cpk and control charts on every measurement to catch drift.
Run explorerOpen the full report of any run with phases, measurements, logs, and attachments.
Unit explorerTrace any unit by serial number across its lifetime.

Use the insights to improve test coverage, stability, or yield in the next Author cycle.

How is this guide?

On this page