platform-engineering · intermediate
Contract Testing for Services
Quick answer
Contract testing checks that a provider and consumer agree on messages/APIs—shape, status codes, required fields—via artifacts exchanged in CI. It catches breaking changes earlier than rare full E2E runs.
Why this matters
- Microservices break at boundaries.
- Full E2E is slow and flaky as graphs grow.
- Complements data contracts and schema registries.
Learning objectives
- Distinguish unit/E2E/contract tests. 2. Write consumer-driven contracts. 3. Verify providers in CI. 4. Version breaking changes. 5. Know limits of contracts.
Explain like I am 5
Before two kids trade lunch notes, agree what "sandwich" means so nobody gets an empty box.
Mental model
flowchart LR
Consumer --> Contract
Contract --> ProviderVerify
ProviderVerify --> CI
Core concepts
Consumer-driven contracts
Consumers publish expectations; providers prove they meet them.Provider verification
Run provider against all consumer contracts on each change.Message contracts
Async events need the same discipline as HTTP.Not a substitute for E2E
Still need a few journey tests; contracts cover boundary compatibility.Worked example
Orders service removes field sku still used by shipping consumer; provider verification fails in CI before prod; dual-publish fix.
Trade-offs
| Only E2E | Only contracts |
|---|---|
| Slow feedback | Misses full journey bugs |
Failure modes
| Mode | Mitigation |
|---|---|
| Outdated contracts | Generate from real traffic carefully / review |
| Testing mocks only | Verify real provider code |
| Ignoring events | Include message schemas |
Interview mode
Skeleton: "Contract tests protect boundaries in CI—consumer expectations verified by providers—plus a few E2E journeys."
Knowledge check
Compatibility between service providers and consumers
CSS pixel perfection only
CPU thermal design
Office seating charts
By Shubham Jain