Identity and Associativity Test Suite¶
Test battery — instantiates Composable Relation Modeling
Runs a battery of cases proving that composing arrows is associative and that the identity arrow truly changes nothing.
An Identity and Associativity Test Suite is an executable battery that checks the two algebraic laws every well-behaved composition must obey: that regrouping a chain of arrows never changes the result — (h ∘ g) ∘ f = h ∘ (g ∘ f) — and that composing with the identity arrow leaves everything untouched — f ∘ id = f = id ∘ f. Its defining feature is that it runs cases against an already-built model and reports pass or fail, rather than declaring types compatible or drawing anything. It presupposes that the arrows connect (that is a type checker's concern); its question is whether, given that they connect, they compose lawfully. A model that violates associativity cannot be safely summarized or refactored, because the very act of regrouping a path would change its meaning; the suite exists to catch exactly that before anyone relies on regrouping.
Example¶
A team ships a text-processing library whose filters — lowercase, trim, redact_pii, collapse_whitespace — are meant to be freely chained. The docs promise you can "compose filters in any grouping" and that a noop filter is available as a neutral element. Before a big refactor that will regroup long filter chains into reusable sub-pipelines, the team builds an Identity and Associativity Test Suite.
The identity cases feed inputs through noop ∘ f and f ∘ noop and assert the output equals f alone — and immediately catch a bug: noop was accidentally trimming a trailing newline, so it was not actually neutral. The associativity cases are the heart of the suite: for triples like redact_pii, lowercase, collapse_whitespace, they compute (collapse ∘ lowercase) ∘ redact and collapse ∘ (lowercase ∘ redact) over a validation case set of adversarial strings and assert the two groupings agree. One triple fails: redact_pii inserts a placeholder token that collapse_whitespace treats differently depending on when lowercase ran, so regrouping shifts the output. The suite's verdict — this chain is not associative around redact_pii — blocks the refactor's plan to regroup that segment, which would otherwise have silently changed results.
How it works¶
- Enumerate triples for associativity. For every composable triple
(f, g, h)in scope, compute both groupings and assert equality over the case set. Associativity is a three-arrow property, so single or double arrows tell you nothing about it. - Enumerate identity cases. For each arrow, compose it with the declared identity on both sides and assert the result is the arrow unchanged. This is what certifies the identity baseline is actually neutral.
- Drive both with an adversarial case set. Laws are quantified over all inputs, so the cases must probe boundaries — empty inputs, order-sensitive tokens, inputs where intermediate arrows touch different state.
- Report law-level verdicts. Output is not "these outputs differ" but "associativity fails around this triple" or "this identity is not neutral," pinned to the offending arrows.
The suite does not check whether arrows are type-compatible to begin with, nor does it adjudicate whether two specific alternative routes are equal — it checks the general laws.
Tuning parameters¶
- Case-set strength — random sampling, hand-picked boundary cases, or exhaustive enumeration over a small domain. Stronger cases catch more law violations but cost more to build and run; a passing suite is only ever as strong as its cases.
- Triple coverage — every composable triple vs. a sampled subset. Full coverage is safest but grows combinatorially; sampling is cheaper but can miss the one bad regrouping.
- Equality relation — exact output equality vs. equality up to a declared tolerance (ordering, whitespace, formatting). Too strict flags cosmetic differences as law failures; too loose blesses real ones.
- Scope of identity checked — one global identity vs. a per-object identity. Per-object is more faithful but multiplies the identity cases.
When it helps, and when it misleads¶
Its strength is that it certifies the two laws that make regrouping and summarizing safe. Without associativity, no path can be collapsed into a named composite without risk; without a true identity, "no-op" steps quietly change results. The suite is the license the refactoring workflow needs before it dares regroup anything.[1]
Its failure mode is the standard limit of testing: a suite that passes has failed to find a violation, not proven there is none, and a thin case set gives false confidence in laws that hold on typical inputs but break on the rare ones. The classic misuse is running only identity cases (easy) and skipping the combinatorial associativity triples (tedious), then treating the model as lawful. A related misuse is loosening the equality relation until failures disappear. The guarding discipline is to make the case set adversarial, to insist on associativity coverage rather than settling for identity checks, and — where the model is small — to prefer exhaustive enumeration or a structural proof over sampling.
How it implements the components¶
associativity_invariant— its core: the battery that verifies regrouping any composable triple leaves the composite unchanged.identity_arrow_baseline— the identity cases that certify the declared identity arrow is genuinely neutral on both sides.diagram_validation_case_set— the adversarial inputs that drive both law checks and localize any failure to specific arrows.
It does not verify that arrows are type-compatible in the first place (source_target_typing_rule, typed_arrow_inventory — that is Source/Target Type Check, its nearest twin; the check asks "can these connect?", the suite asks "given they connect, do they compose lawfully?"), and it does not enumerate the composites themselves (composition_rule — that is Composition Table).
Related¶
- Instantiates: Composable Relation Modeling — the suite is the archetype's law-verification battery.
- Consumes: Composition Table supplies the composites whose laws are tested; Source/Target Type Check certifies the arrows connect before the laws are checked.
- Sibling mechanisms: Source/Target Type Check · Composition Table · Object–Arrow Diagram · Commutative Path-Equivalence Diagram · Interface-Contract Category Map · Functorial Transfer Probe · Structure-Preservation Checklist · Categorical Refactoring Workflow
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Identity and Associativity Test Suite operates as a bounded trial, probe, simulation, or rehearsal that generates evidence from performance because it runs a battery of cases proving that composing arrows is associative and that the identity arrow truly changes nothing
Independent corroboration: The frozen evidence defines Identity and Associativity Test Suite as 'Runs a battery of cases proving that composing arrows is associative and that the identity arrow truly changes nothing', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Mathematics
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Associativity and a two-sided identity are the defining monoid laws from abstract algebra and category theory.
Related originating lineages:
- Computer Science & Software Engineering — Property-based testing and composable software abstractions materially operationalize the laws as an executable suite.
Review resolution: Both reviewers independently assign mathematics as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The evidence describes one principal historical lineage. It has established independent use across several domains, but that does not make it domain-free. The encyclopedia entry makes that composition explicit.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Fowler, M. Refactoring: Improving the Design of Existing Code. 2nd ed. Addison-Wesley Professional (2018). Treats a solid self-checking test suite as the practical safety net that makes behavior-preserving refactoring possible. registry ↩