Back to Catalog
Microservices
Testing
Consumer-Driven Contract Test
Consumer defines what it needs from a provider — provider proves it delivers. No end-to-end tests needed.
Intent & Description
Real-world Use Case
Order Service (consumer) defines: “I call GET /menu/{id} and expect {id, name, price}”. Restaurant Service (provider) runs Pact tests on every PR. If they remove “price”, the build fails immediately.
Source
📌 TL;DR
Consumer writes what it needs, provider proves it delivers. Cheap, fast, and kills the “you broke my API” blame game.
Advantages
- Catches breaking API changes at build time, not in prod
- No flaky end-to-end test environments needed
- Self-documenting — contracts describe actual usage
- Enables independent deployments with confidence
Disadvantages
- Teams need discipline to write and maintain contracts
- Pact Broker or equivalent infra needed
- Doesn’t catch logic bugs — only structural/contract violations
- Learning curve for teams new to contract testing