- ID
- 8ca107d6-7ace-4dc0-a026-e29ff7c3f87c
Contract Testing: Colin's Proposal vs Henry's Sodapop RFC
Sources
- [[https://hungryroot.atlassian.net/wiki/spaces/BA/pages/1535868929/Backend+Project+Proposal+Contract+Testing+with+Schemathesis+and+Pact][BE: Contract Testing with Schemathesis and Pact]] (Colin Powell)
- [[https://hungryroot.atlassian.net/wiki/spaces/WD/pages/1584168961/RFC+Client-Safe+Sodapop+UI+Attachments+and+Suggested+Action+Contracts][RFC: Client-Safe Sodapop UI Attachments and Suggested Action Contracts]] (Henry Ng)
Where They Align
Both propose Pact for consumer-driven contract testing. Same model:
- Consumers: web, iOS, Android
- Provider: server
- Goal: block incompatible deploys
Both enforce explicit contract versioning (=action.add.v1=, =action.add.v2=) and
deprecation windows. Philosophically identical.
Where They Differ
| Dimension | Colin (BE) | Henry (Sodapop RFC) |
|------------------------+------------------------------------------+--------------------------------------------------|
| Layer | REST API schema (OpenAPI/DRF) | Sodapop AI response UI contracts |
| Problem | Schema drift: spec ≠ implementation | Capability mismatch: server emits UI clients can't render |
| Phase 1 | Schemathesis (OpenAPI validation) | Capability registry + server-owned profiles |
| Pact path | Pact Broker (PactFlow) from Phase 2 | Lightweight path (shared fixtures + CI) first, broker later |
| Novel concept | None beyond standard Pact | Server-side capability profiles by client identity |
| Conversation history | Not addressed | Full cross-platform replay safety model |
| Owners defined? | Placeholder [Assign Owner] | Henry authored; resolution location open question |
Key Tensions
Two Pact setups, one broker question
Colin's doc plans PactFlow from Phase 2. Sodapop RFC defers broker until
"fixtures become painful." If web ships the lightweight path first, we could
end up with divergent contract validation infrastructure before Phase 2 lands.
Scope gap
Colin's doc covers the Django REST API. Sodapop RFC covers Sodapop AI
responses. Neither covers the other's domain — but both need Pact, so the
broker ownership and CI integration need to be shared infrastructure, not two
separate things.
Capability registry is unowned
Sodapop RFC leaves open: "should resolution live in Hungryroot API layer or
Sodapop?" — that's a backend decision that directly affects Phase 2 scope.
Practical Synthesis
Colin's Phase 1 (Schemathesis) is orthogonal to the Sodapop RFC — no
conflict, different layer entirely. Start it independently.
Colin's Phase 2 (Pact Broker) *is* the Sodapop RFC's "Contract Testing With
Pact" section. Henry's doc even says as much. The smart move: coordinate on a
single shared Pact Broker before either team sets one up solo. Colin's doc has
the infra plan; Henry's doc has the Sodapop-specific contracts. They need each
other.
Recommend getting Henry into the Phase 2 kickoff (already scheduled June 3).
The capability registry ownership question is a blocker for both.