← CodeClarityLab Home
Browse by Category
+ added · updated 7d
← Back to glossary

Consumer-Driven Contract Testing

testing Advanced

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)

Added 15 Mar 2026
Edited 22 Mar 2026
Views 58
Rate this term
No ratings yet
🤖 AI Guestbook educational data only
| |
Last 30 days
0 pings W 0 pings T 0 pings F 0 pings S 0 pings S 0 pings M 0 pings T 0 pings W 0 pings T 0 pings F 0 pings S 0 pings S 0 pings M 0 pings T 1 ping W 0 pings T 2 pings F 2 pings S 1 ping S 0 pings M 0 pings T 1 ping W 1 ping T 1 ping F 1 ping S 0 pings S 0 pings M 0 pings T 0 pings W 0 pings T
No pings yet today
No pings yesterday
Amazonbot 16 Perplexity 11 Google 9 ChatGPT 7 Unknown AI 4 Ahrefs 2 Majestic 1 DuckDuckGo 1
crawler 47 crawler_json 2 pre-tracking 2
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

✓ schema.org compliant