Testing

Verification in this workspace is layered, and the layers are not interchangeable. A unit test pins an example. A property test pins a law. A conformance harness pins a contract that spans crates and belongs to none of them. A gate pins a claim about the repository itself, including claims made in prose. A smoke test proves a real venue still answers the way the adapter believes. A latency gate proves a tail. Each tier catches a failure class the tier below it structurally cannot see, which is why all six exist rather than one very large test suite.

The tiers

Unit and golden

The bottom tier is ordinary: #[cfg(test)] modules next to the function they pin. Above them sit the frozen golden fixtures — exported once, then frozen, with every exporter deleted from the tree, so the committed bytes are the oracle and the comparisons stay exact. Floats are IEEE-754 hex bit patterns, and the rule that governs them is a review rule rather than a mechanical one: never widen a tolerance to make a test pass. The parity gate is what that means in full, and adding to the parity suite is the procedure.

Property

Golden fixtures pin examples somebody chose. proptest suites pin the laws those examples were supposed to illustrate, over inputs nobody chose. crates/vike-exec/tests/order_fsm_props.rs folds arbitrary lifecycle-event sequences through the order FSM and asserts six laws including terminal absorption and error purity; crates/vike-model/tests/scalar_props.rs asserts grid-rounding idempotence with exact equality. The workspace convention is that a counterexample is a real finding: stop, report, and commit the generated proptest-regressions/ seed so it reproduces. See property tests.

Conformance

Two harnesses in crates/vike-bridge-core/tests/ machine-check the venue-adapter contract that no single venue crate contains. The exec contract runs one scenario table against every covered venue's real event mapper folded through the real vike_exec::ManagedOrder FSM. The market-data contract runs one invariant table against every covered venue's real L2-book normalizer. Each carries a roster gate so a new venue is either covered or deferred with a written reason — never silently absent.

Gate

A gate is a test whose subject is the repository. Layering, the derived CI crate roster, the settings registry, the per-venue capability tables, the committed generated artifacts, and prose itself — citations, unrun commands, duplicated constants — all have one. The whole family, and how to read a failure from each, is the developer guide. Two gates belong to this section specifically: the wire quantizers source gate, and the smoke-lane credential guard described under live smokes.

Smoke

Every venue's *_smoke.rs is #[ignore]d, so an ordinary cargo test never runs one. Most are credential-gated on top of that and self-skip unless demo credentials are present in the project credential store. The keyless ones are not: where a smoke reaches no account — public streams and REST, or a local accepting client — there is no credential to gate on and #[ignore] is the only gate; Polymarket's Gamma catalog smoke gates on an explicit POLY_GAMMA_SMOKE=1 instead. Some place real orders on demo accounts. They are the only tier that can catch a venue changing its wire, and the only tier that touches an account, which is why they are never run casually.

Latency

crates/vike-core/tests/runtime_latency.rs holds both gates and measurements, and its header is explicit that only three of its tests assert a derived ceiling. Everything else measures: the submit, book and coid variants assert nothing about timing at all, and the snapshot-build one keeps a 1 ms p50 sanity ceiling its own comment calls a liveness check rather than a budget. The split is deliberate — as that file puts it, an uncalibrated ceiling is a flaky gate, "which is worse than no gate at all because people learn to re-run it rather than read it." The meaning is the latency gate; the procedure is running the latency gate.

Two rules that cut across every tier