Contract testing verifies that two services (consumer and provider) can communicate correctly without requiring them to run together. The consumer defines a "contract" (expected request/response format), the provider verifies it can fulfil that contract. Pact is the most popular framework. Benefits over integration testing: faster feedback (no real service needed), clear ownership (consumers define contracts), and independent deployability (verify compatibility without full environment).
Each stage in order — click any step to read what it does.
How Pact contracts flow from consumer to provider.
The trade-offs worth knowing before you build this.
With contract testing, you can deploy the consumer independently of the provider — just run 'can-i-deploy' first. This is the technical enabler for microservice teams to deploy without coordinating with every other team.
A contract test runs in seconds (mock server, no real network). An equivalent integration test requires both services running, database seeded, and network configured — often 10-30x slower and flakier.
The consumer team writes what they expect, not the provider team. This prevents providers from 'designing' contracts that don't reflect actual usage, and gives providers a clear test suite to verify against.
Sign in to share your feedback and join the discussion.
