Online vs Offline
pytest-f3ts runs the same test plan whether or not a backend is reachable. It does this with two API clients behind one interface and an automatic fallback.
Two clients, one interface
| Client | When | What it does |
|---|---|---|
F3TSBackendAPI | a backend is reachable | Real integration: HTTP calls to the backend REST API plus websocket pushes to the frontend, wrapped in retries. |
F3TSASCIIAPI | offline / local | Same method names (send_test_result, update_run_data, send_user_notif, send_banner_update, send_serial_number, …) but it accumulates everything into an in-memory dict instead of making network calls. |
Because both clients expose the same methods, the rest of the plugin doesn't care which one is active.
Automatic fallback
When the reporter starts up it tries to construct F3TSBackendAPI. On any exception (no --backend_url, backend unreachable, etc.) it logs a warning and swaps in F3TSASCIIAPI. So a run with no backend prints two expected warnings and then continues locally:
WARNING: Unable to connect to backend API ...
Invalid URL 'None/runs/DEV': No scheme supplied.The opt-in fixtures follow the same rule: the backend_api fixture returns None offline, and fixtures like user_dialog and status_banner detect that and fall back to the terminal instead of driving the GUI. (serial_number simply records the value locally when offline.)
How "offline" is detected
The active client exposes api_url. Offline, api_url is None. The plugin uses this at the end of a run to decide whether to print the local summary table (online runs skip it — the results are already in the backend).
Why it matters
You can develop and debug a full test plan on your laptop with no backend, no GUI, and no hardware (see Your First Test). The same plan then runs unchanged on the FixturFab Test Runner, where the online client takes over and streams results live.