Testing

Runs have real side effects — they post to Slack, send email, change ad budgets — and every live run costs tokens. Your integration tests should never hit the live API. m8tes.testing (SDK 4.8.0+) runs your code against the real client with only the network swapped out:

The mock is mounted at the transport layer, so retries, idempotency keys, typed error mapping, and SSE parsing are all the production code paths. It needs no extra dependencies and no running server.

Test your failure paths

The first thing worth testing is what your code does when a run fails. Build a failing stream, or a full error envelope:

Fixtures for the same route are consumed in order (that's how you script a status poll), so use a fresh client — or distinct routes — per scenario. And mocked 429/500 responses are retried by the real client with real backoff (~1.5s): that's the production retry path doing its job, so prefer 4xx fixtures and assert on client.mock.calls counts instead of timing.

Use your own client construction

If your app builds its own M8tes (from config, per tenant, ...), install the transport into it instead of using MockM8tes:

Pin the tenant scope

A query string on a fixture makes it query-aware: the request must carry those parameters, so a test whose code drops user_id fails instead of silently matching. mock.calls records the parsed query as params for direct assertions. This is the test that keeps multi-tenant isolation honest:

Fixtures without a query string match any query. Recorded headers are credential-redacted (Authorization becomes <redacted>), so snapshots and CI logs never carry a real key.

Payload factories

agent_payload, run_payload, task_payload, and page_payload build realistic v2 wire shapes with sensible defaults — override only what your test cares about. error_envelope builds the standard error format, including error_code.

For end-to-end verification against a real backend before going live, use a separate account with a small balance — see Going Live.