testing/cross_backend/ready.ts

Cross-backend parity suite for the /ready schema-drift deploy gate.

The /ready mechanism already ships on both twins (TS create_ready_route_spec / db/schema_ready.ts; Rust fuz_http::ready / fuz_db::schema_ready), each with its own drift → 503 unit tests. This suite is the missing automated cross-impl gate: an anonymous GET /ready returns 200 {ready: true} over real HTTP on both spine test servers, proving the success path is wire- identical and that both backends read the same committed expected_schema.json (column-presence is engine-portable, so one fixture is the cross-impl contract).

/ready is a plain public REST route — not an RPC method, not one of the six REST auth routes — and it's deliberately off the declared spine surface (create_spine_surface_spec), like ws/sse/cells/fact-serving. So it needs a bespoke imperative suite (à la origin.cross.test.ts), gated on capabilities.ready, rather than a conformance_table row or generic round-trip enumeration. The drift → 503 path stays per-impl unit tests.

Runs both legs via the shared {setup_test, capabilities} protocol: the in-process leg (cross_backend/ready_parity.db.test.ts, plain gro test) and the cross-process leg (cross_backend/ready.cross.test.ts, the TS spine binaries + Rust testing_spine_stub over real HTTP).

$lib-free by contract (relative specifiers only), like the sibling cross-backend suites.

view source

Declarations
#

2 declarations

describe_ready_cross_tests
#

ReadyCrossTestOptions
#

testing/cross_backend/ready.ts view source

ReadyCrossTestOptions import type {ReadyCrossTestOptions} from '@fuzdev/fuz_app/testing/cross_backend/ready.js';

Options for the readiness-probe parity suite.

inheritance

ready_path?

Readiness probe path. Default /ready.

type string

readonly

Depends on
#