Consumer-Driven Contract Testing
Also Known As
CDC testing
Pact
contract test
TL;DR
A testing approach where the consumer of an API defines a contract of what it expects, and the provider verifies it satisfies that contract — enabling independent deployment of microservices.
Explanation
In microservices, integration tests require both services running simultaneously — slow, fragile, and hard to maintain. Consumer-Driven Contract Testing (CDC) with Pact solves this: the consumer writes tests defining what request/response it expects, generating a contract (pact file). The provider then runs its own verification against the contract without needing the consumer running. Both can deploy independently once the contract is satisfied.
Diagram
sequenceDiagram
participant CONS as Consumer
participant BROKER as Pact Broker
participant PROV as Provider
CONS->>CONS: Write consumer test<br/>define expected request/response
CONS->>BROKER: Publish contract pact file
Note over CONS,BROKER: Consumer CI passes
PROV->>BROKER: Fetch contract
PROV->>PROV: Verify provider meets contract
PROV-->>BROKER: Verification result
BROKER-->>CONS: Can I deploy? yes/no
Common Misconception
✗ Contract testing replaces integration testing — it verifies API contracts are compatible, not that the full business flow works end-to-end; both are needed.
Why It Matters
Without contract testing, microservices break each other silently when APIs change — contract tests catch breaking changes before deployment, not after an incident.
Common Mistakes
- Provider teams writing contracts rather than consumers — the whole point is the consumer defines what it needs.
- Not publishing contracts to a broker (Pact Broker) — contracts stored locally cannot be verified by the provider CI.
- Contracts that are too strict — specifying exact response body structure breaks on innocuous additions.
- Not running contract verification in the provider's CI — contracts only help if the provider actually checks them.
Code Examples
✗ Vulnerable
// No contract testing — provider changes break consumer silently:
// Provider team renames 'user_id' to 'id' in response
// Consumer code: $response['user_id'] — now null
// Discovered in production, not in CI
// Both teams deployed independently with no coordination
✓ Fixed
// Consumer defines contract (Pact PHP):
$builder->uponReceiving('a request for user 42')
->with(['method' => 'GET', 'path' => '/users/42'])
->willRespondWith([
'status' => 200,
'body' => ['user_id' => 42, 'name' => Matchers::like('Alice')]
]);
// Pact file published to broker
// Provider CI verifies: GET /users/42 returns user_id (not id)
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
58
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Amazonbot 16
Perplexity 11
Google 9
ChatGPT 7
Unknown AI 4
Ahrefs 2
Majestic 1
DuckDuckGo 1
Also referenced
How they use it
crawler 47
crawler_json 2
pre-tracking 2
Related categories
⚡
DEV INTEL
Tools & Severity
🟡 Medium
⚙ Fix effort: High
⚡ Quick Fix
Write Pact consumer tests that define what your PHP service expects from each dependency — the provider runs these expectations as part of its own test suite
📦 Applies To
any
web
api
🔗 Prerequisites
🔍 Detection Hints
E2E tests as only way to verify API compatibility between services; breaking changes caught only in staging or production
Auto-detectable:
✓ Yes
pact
pact-php
pactflow
⚠ Related Problems
🤖 AI Agent
Confidence: Medium
False Positives: Medium
✗ Manual fix
Fix: Medium
Context: File
Tests: Update