Bijection Test Suite¶
Test or assessment — instantiates Lossless Bijective Mapping Design
Automated or manual tests checking no duplicate targets, no orphaned targets, no missing sources, and correct round trips.
A bijection test suite is the assembled, repeatable battery that asserts the whole bijection contract at once and gates a change on the result — the thing that runs in CI before a mapping ships, not the individual probe that looks at one property. Its defining move is orchestration and verdict: it composes the focused checks (the collision check, the orphan scan, the round-trip run), adds a fast cardinality-balance pre-flight of its own, and collapses everything into a single machine-readable pass/fail with an evidence trail attached. A lone scan tells you whether targets are shared; the suite tells you whether this mapping is a bijection, right now, and here is the proof. Because it is a gate, it is written to be run a thousand times unattended, so its output is not a human report but a signed record a pipeline can act on.
Example¶
A payments team maintains a reconciliation layer that pairs every internal order_id with exactly one processor transaction_id. The pairing has to stay bijective or money silently double-counts. So a bijection test suite runs on every deploy and every nightly load. It first does its own cheap cardinality-balance check — count distinct orders, count distinct transactions, and if the two totals differ, fail fast before spending effort on anything deeper. It then runs an injectivity assertion: no transaction_id may appear against two different orders. For the surjectivity and round-trip legs it does not re-implement the logic; it invokes the sibling scans, gathering their findings under one roof.
The suite finishes by writing a signed test record — commit hash, dataset snapshot ID, each assertion's status, and the count of rows examined — into the build log. When a nightly run flips from green to red on the injectivity assertion, the pipeline blocks promotion automatically and the record shows exactly which run introduced the first shared transaction. Nobody argues about whether the mapping "seems fine"; the proof is the gate.
How it works¶
- Fail fast, then fail deep. A cardinality-balance pre-flight runs first because it is O(count) and rules out whole categories of failure cheaply; the expensive per-pair assertions only run if the counts already agree.
- Compose, don't duplicate. The suite owns the injectivity assertion and the count check; for surjectivity and round-trip it calls Orphan Target Scan and Round-Trip Migration Test and aggregates their verdicts, so each property has exactly one authoritative implementation.
- Emit a verdict, not a narrative. Output is a structured pass/fail per assertion plus a rolled-up status a machine can branch on.
- Sign the record. Each run is stamped with the inputs it saw (dataset version, code revision) so a green run is reproducible and a red run is attributable.
Tuning parameters¶
- Gate strictness — whether a single red assertion blocks promotion or only warns. Blocking protects the invariant but can halt delivery on a benign data-quality blip; warning keeps flow but lets drift accumulate.
- Assertion coverage — which properties are in the battery (injectivity, count balance, surjectivity, round-trip, boundary cases). More assertions catch more, but each adds runtime and a maintenance surface.
- Sample vs. exhaustive — run against the full population or a sampled slice. Sampling makes the suite fast enough for every commit at the cost of missing rare collisions.
- Run cadence — per-commit, per-deploy, or nightly. Frequent runs localize the introducing change; infrequent runs are cheaper but widen the blame window.
- Evidence verbosity — how much of the failing rows the record captures. Rich evidence speeds repair but can leak sensitive data into build logs.
When it helps, and when it misleads¶
Its strength is that it turns "is this still a bijection?" into a button — a single, reproducible verdict that a delivery pipeline can enforce without human judgment, and a history of signed records that makes any regression attributable to one run. It is the mechanism that keeps a mapping bijective over time rather than just at design.
Its honest failure mode is the oracle problem: a test suite only checks the properties someone thought to assert, so a green suite proves the absence of the failures it looks for, never bijectivity in general.[n1] The classic misuse is trusting a sampled suite as if it were exhaustive — it runs fast, stays green, and quietly never examines the one partition where collisions live. It also inherits its verdict from the siblings it consumes: if the orphan scan's boundary is wrong, the suite reports green over a real gap. The guarding discipline is to grow the assertion set every time a real defect slips through (so the suite only ever gets stricter), and to run exhaustively — not sampled — before any irreversible cutover.
How it implements the components¶
injectivity_guard— the suite owns the assertion that no target value is claimed by two distinct sources, run as a hard check on every pass.cardinality_balance_check— its cheap first gate compares distinct-source and distinct-target counts and fails fast on any imbalance.proof_or_audit_record— every run emits a signed, reproducible record of inputs and per-assertion results that a pipeline treats as the authoritative verdict.
It does not implement surjectivity_coverage_guard — that leg is owned by its nearest test-cluster twin Orphan Target Scan — nor round_trip_test_set, owned by Round-Trip Migration Test; the suite invokes both rather than re-implementing them.
Related¶
- Instantiates: Lossless Bijective Mapping Design — the suite is the archetype's standing verification gate, asserting the contract on every change.
- Consumes: Orphan Target Scan for the surjectivity leg and Round-Trip Migration Test for the round-trip leg.
- Sibling mechanisms: Orphan Target Scan · Round-Trip Migration Test · ID Mapping Register · One-to-One Crosswalk Table · Inverse Index · Reversible Encoder–Decoder Pair · Unique-Constraint Pair · Mapping Exception Queue
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Automated or manual tests checking no duplicate targets, no orphaned targets, no missing sources, and correct round trips, making its operative form a deliberate probe, variation, simulation, or practiced execution used to generate evidence or readiness.
Independent corroboration: The frozen evidence defines Bijection Test Suite as 'Automated or manual tests checking no duplicate targets, no orphaned targets, no missing sources, and correct round trips', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Software verification operationalizes the mathematical bijection contract as repeatable injectivity, surjectivity, cardinality, and round-trip assertions in a release gate.
Related originating lineages:
- Mathematics — Mathematics contributes the formal structure, proof, asymptotic, combinatorial, or numerical foundation used here.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] The test oracle problem: to judge a test's outcome you need an oracle that says what the correct result is, and for most non-trivial properties no complete, cheap oracle exists. A passing suite therefore certifies only the specific assertions it encodes, which is why the assertion set must grow with every escaped defect. ↩