What is contract testing and how does consumer-driven contract testing work?
Understand contract testing and how consumer-driven contract testing works, with Pact examples, provider verification and microservices interview tips.
Expected Interview Answer
Contract testing verifies that two services agree on the shape of their interaction — the requests one sends and the responses the other returns — without running both together. In consumer-driven contract testing, the consumer defines its expectations as a contract, and the provider is tested against that contract to prove it will not break the consumer.
The consumer's tests record the exact requests it makes and the responses it needs, producing a contract file (a pact). This contract is shared, often via a broker, with the provider team. The provider replays those interactions against its real implementation to verify it still returns everything the consumer relies on. Because the check happens on each side independently, teams catch breaking API changes at build time rather than in a slow, brittle end-to-end environment. Consumer-driven means the consumers' real needs — not a speculative full spec — drive what the provider must guarantee, so providers only promise what someone actually uses.
- Catches breaking API changes before deployment
- No need to run both services together to verify compatibility
- Providers only guarantee what consumers actually use
- Enables independent, decoupled team deployments
- Fast and stable compared with end-to-end tests
AI Mentor Explanation
A batter tells the bowling machine operator exactly which deliveries to feed for practice: length, line and pace. That written request list is the consumer contract. Before the season the operator checks the machine can actually bowl every one of those deliveries. If a setting changed and one delivery is no longer possible, they know now, not when the batter faces it in a real match.
Step-by-Step Explanation
Step 1
Consumer defines expectations
The consumer's tests describe each request it sends and the response fields it depends on, generating a contract file.
Step 2
Publish the contract
The pact is uploaded to a broker or shared artifact so provider teams can discover the versions consuming them.
Step 3
Provider verifies
The provider replays the recorded interactions against its real implementation to confirm it satisfies each one.
Step 4
Fail the build on mismatch
If the provider no longer returns a required field or status, verification fails before the change is deployed.
Step 5
Gate deployment with can-i-deploy
Use broker checks to ensure a provider or consumer version is compatible with everything currently in production.
What Interviewer Expects
- Clear definition of a contract as an interaction agreement
- Understanding that consumers drive the expectations
- How providers verify against recorded interactions
- Awareness of a broker and can-i-deploy gating
- Why this beats end-to-end tests for compatibility
Common Mistakes
- Confusing contract tests with schema validation only
- Thinking the provider, not the consumer, writes the contract
- Skipping provider verification so contracts go stale
- Testing fields the consumer never actually uses
- Not versioning contracts, breaking backward compatibility checks
Best Answer (HR Friendly)
“Contract testing makes two services agree on how they talk before they ever run together. The service that makes the call writes down exactly what it needs, and the other service is checked against that list. If someone changes the interface in a breaking way, the test fails early instead of causing a live outage.”
Code Example
const { Verifier } = require('@pact-foundation/pact')
describe('Payments provider verification', () => {
it('honours the OrdersService contract', () => {
return new Verifier({
provider: 'PaymentsService',
providerBaseUrl: 'http://localhost:4000',
pactBrokerUrl: process.env.PACT_BROKER_URL,
publishVerificationResult: true,
providerVersion: process.env.GIT_SHA,
stateHandlers: {
'payment 42 exists': async () => seedPayment(42, 'CAPTURED'),
},
}).verifyProvider()
})
})Follow-up Questions
- How does a Pact broker help coordinate teams?
- What does the can-i-deploy check do?
- How is consumer-driven contract testing different from OpenAPI schema validation?
- How do you handle provider states in verification?
- Can contract testing work for asynchronous message-based services?
MCQ Practice
1. In consumer-driven contract testing, who defines the contract?
The consumer records the requests it makes and responses it needs, and the provider is verified against that.
2. What is the main advantage of contract testing over end-to-end testing?
Each side is verified independently, giving fast, stable compatibility checks instead of slow, flaky E2E runs.
3. What does a can-i-deploy check confirm?
It uses the broker's contract data to confirm a consumer or provider version is safe to deploy against current partners.
Flash Cards
What is a pact? — A contract file recording the requests a consumer makes and the responses it expects from a provider.
Who drives consumer-driven contracts? — The consumers; providers only guarantee the interactions consumers actually rely on.
What is provider verification? — Replaying a consumer's recorded interactions against the real provider to confirm it still satisfies them.
What is the can-i-deploy check? — A broker query confirming a version is compatible with the versions currently in production before release.