testing/transports

4 modules

• testing/transports/bootstrap.ts

  Stateless cross-process bootstrap.

  POSTs {bootstrap_path} against the running test binary with the preconfigured token + username + password, parses the BootstrapOutput envelope, captures the session Set-Cookie onto the supplied FetchTransport (which carries it on every subsequent call), and returns the keeper credentials.

  Fires exactly once per backend lifetime — spawn_backend calls it inside vitest's globalSetup. Per-test fixtures re-use the captured keeper credentials; fresh per-test accounts come from fixture.create_account() (signup+login through production RPC), not re-bootstrap. The hybrid reset model in default_cross_process_setup depends on this — re-bootstrap would race the bootstrap lock and in-memory caches.

• testing/transports/fetch_transport.ts

  Cookie-threading HTTP transport for cross-process tests.

  Wraps the global fetch against a base URL, carries cookies across requests in a Map-backed jar so the session cookie set on bootstrap is re-sent on every subsequent call. Satisfies the RpcTestTransport shape Hono.request already does — so every suite body that takes transport: RpcTestTransport works against a cross-process binary unchanged.

  The Origin header is threaded onto every request because the backend's allowlist ({ZZZ,ZAP,FUZ}_ALLOWED_ORIGINS) rejects mutations without an Origin. Cross-process tests run with ALLOWED_ORIGINS=http://localhost:*, so defaulting origin to the configured base_url is safe.

  The cookie jar is intentionally simple — it does not honour Domain, Path, Expires, or SameSite attributes. Cross-process tests always hit a single host:port, so name-keyed last-write-wins matches the behaviour real browsers exhibit against the same surface.

• testing/transports/ws_client.ts

  Shared WebSocket client surface for cross-backend tests.

  WsClient is the interface every in-process or cross-process WS test driver implements — send / request / close / messages / wait_for. Two impls today:

  - In-process — create_ws_test_harness in ../ws_round_trip.ts. Drives register_action_ws against a fake Hono upgrade so the dispatcher's full path runs without the wire upgrade. - Cross-process — create_ws_transport in ./ws_transport.ts. Wraps the native WebSocket upgrade against a real running binary, threading the session cookie captured by FetchTransport.

  Wire-frame types + predicates also live here so both impls (and every shared assertion helper) reference one source.

• testing/transports/ws_transport.ts

  Cross-process WebSocket transport.

  Implements the shared WsClient interface (see ws_client.ts) over a real WebSocket upgrade against a spawned test binary. The cookie captured by the sibling FetchTransport on bootstrap is threaded onto the upgrade request so the WS session authenticates as the same account.

  Uses the ws npm package — Node's native WebSocket (from undici) follows the WHATWG spec strictly and doesn't accept custom request headers on construction, so cookie-on-upgrade requires the ws package's headers option. fuz_app declares ws as an optional peerDependency — consumers wiring cross-process tests install it themselves (npm install --save-dev ws).