With the Test Runner

The FixturFab Test Runner is the GUI application operators use to run a test plan on a fixture during manufacturing. It runs your pytest plan unchanged — everything you built and debugged locally works the same way here, with results shown live and stored in a database. This page is the test author's view of that integration; the operator's UI steps live in the Test Runner's own operator guide.

How your plan gets there

1. A plan is a directory containing a test_plan.py (plus its config.yml, conftest.py, interface.py, etc. — see Creating a Test Plan). The Test Runner discovers a plan by finding that directory.
2. An administrator registers it in the Test Runner. Registration reads your config.yml and stores the plan, giving it a plan_id. The runner_settings, test_cases, and fixture_settings you wrote become the plan's runner configuration, limits, and per-slot settings.

How it runs your plan

When an operator starts a run, the Test Runner launches your plan as a normal pytest process with the f3ts plugin, roughly:

pytest -p f3ts --f3ts_config=config.yml \
  --backend_url <backend>/api/v1 \
  --run_id <run> --plan_id <plan> \
  --slot_id <slot> --frontend_client_id <client>

You don't type this — the runner sets these CLI options for you. With --backend_url present, the plugin uses its online client: each result is sent over REST and pushed to the GUI over a websocket, so the operator sees tests pass/fail in real time. See Online vs Offline and Result Reporting.

What config.yml controls in the GUI

Your config.yml drives the runner:

• runner_settings (GUISettings) — display name, whether to stop at the first failure, autorun, and the DUT count/grid for multi-up fixtures.
• test_cases — the test_id, description, limits, and error codes/messages shown next to each result and in the operator's debugging guidance.
• fixture_settings — per-slot values your tests read through fixture_config.

Multi-up fixtures and slots

A fixture that tests several boards at once gives each DUT a slot. The runner passes a --slot_id, and the plugin selects the matching fixture_settings entry. Read per-slot values (board serials, MAC addresses, calibration) from fixture_config, and your results are labeled with the slot they came from.

Serial numbers and operator interaction

• Capture the DUT serial with the serial_number fixture — on the runner it updates the run record and GUI; offline it just stores the value.
• Prompt the operator with user_dialog (barcode scans, visual checks) and update the GUI banner with status_banner. All three degrade to the terminal when you run locally.

Develop locally, deploy unchanged

Because the plugin degrades gracefully, the workflow is: build and debug the plan locally with the mock/offline path, then register it with the Test Runner. No test code changes between the two — only whether a backend is connected.