Files
correx/docs/decisions/adr-0008-contract-enforcment-with-tests.md
T

2.1 KiB

name, description, depth, links
name description depth links
Adr 0008 Contract Enforcment With Tests Contract testing to enforce event and replay invariants 2
../index.md
./adr-0006-event-store-append-only.md
./adr-0007-projection-replay.md

ADR-0009: Contract Testing Enforcement of Event & Replay Invariants

status: accepted date: 08.05.2026 deciders: Kami


context

System correctness depends not only on design-time invariants (ADR-0007, ADR-0008) but also on continuous enforcement across implementations.

Multiple EventStore and Replay implementations exist (in-memory, sqlite, future persistence layers). Without shared contract tests, invariants may diverge silently.

This ADR defines the role of contract tests as enforcement layer for system invariants.


content

1. contract-first enforcement model

  • all EventStore implementations MUST satisfy shared contract tests
  • all replay implementations MUST satisfy shared replay contracts

2. EventStore contract requirements

Contract tests MUST enforce:

  • append-only behavior
  • idempotency of event_id
  • strict ordering per session
  • deterministic read consistency
  • correct sequence continuity

3. Replay contract requirements

Contract tests MUST enforce:

  • deterministic reconstruction of state
  • identical results across repeated replay executions
  • correctness over full event streams
  • correctness over partial event streams (cursor-based replay)

4. implementation independence

  • contract tests MUST NOT depend on specific implementation details
  • tests operate only through interfaces (EventStore, EventReplayer, Projection)

5. cross-backend equivalence

  • in-memory and persistent stores MUST produce identical replay results for identical inputs

consequences

positive:

  • prevents divergence between implementations
  • guarantees correctness across persistence backends
  • enforces architectural invariants at CI level
  • makes replay correctness regression-resistant

negative:

  • increases test suite complexity
  • requires careful abstraction of test fixtures
  • slower feedback cycles for persistence changes

status

accepted