Problem
Even once each crate has unit tests, nothing exercises the three together. The
protocol's value is the composition — attest, meter, settle — and that is
where the interesting bugs live: mismatched assumptions at the seams between
contracts that each behave correctly alone.
What to do
Add an integration-tests workspace member registering all three contracts in
one Env:
- Full happy path: register model → attest → meter → open escrow → window
elapses → release. Assert balances and state at each step.
- Dispute path: attest → meter → dispute raised → adjudicated split → both
parties paid correctly.
- Adversarial paths: metering an attestation twice, settling an escrow twice,
disputing after the window, superseding an already-settled attestation.
- Assert cross-contract invariants: total settled never exceeds total
metered; every settlement traces to an attestation.
Acceptance criteria
Notes
The invariant assertions are the durable part. Individual test cases go stale;
"total settled never exceeds total metered" stays true for the life of the
protocol and will catch changes nobody thought to test.
Problem
Even once each crate has unit tests, nothing exercises the three together. The
protocol's value is the composition — attest, meter, settle — and that is
where the interesting bugs live: mismatched assumptions at the seams between
contracts that each behave correctly alone.
What to do
Add an
integration-testsworkspace member registering all three contracts inone
Env:elapses → release. Assert balances and state at each step.
parties paid correctly.
disputing after the window, superseding an already-settled attestation.
metered; every settlement traces to an attestation.
Acceptance criteria
Notes
The invariant assertions are the durable part. Individual test cases go stale;
"total settled never exceeds total metered" stays true for the life of the
protocol and will catch changes nobody thought to test.