Why contract testing is important in microservices

• Integration risk – Services are deployed independently, so a provider can change its API and break consumers without either team noticing.
• Unit tests insufficient – Each service's unit tests pass while the interface between them is broken.
• E2E tests insufficient – Catch the break but are slow, flaky, require standing up many services, and undermine independent deployment.
• Contract testing fills the gap – Tests the interface agreement independently and fast, encoding consumer expectations as a verifiable contract.
• Deployment gate – The Broker's can-I-deploy blocks incompatible versions automatically.
• Scales – Pairwise contracts are manageable; full E2E grows combinatorially with service count.

Why does independent deployment create integration risk?

Microservices gain their benefit from being decoupled, but that independence creates the risk that interfaces drift apart.

  Accounts Service                 Transfers Service
  ─────────────────               ─────────────────
  v1: { balance: 50000 }   ──>   Reads: response.balance
  v2: { amount: 50000 }    ──>   Reads: response.balance  -> UNDEFINED!
       ^                                  ^
       renamed field                      consumer breaks
       unit tests still pass              unit tests still pass

Why are unit tests insufficient?

Each service's unit tests pass because they test internal logic, not the interface between services.

// Accounts Service unit test: PASSES
@Test
void getBalance() {
    Account acc = accountService.getBalance("ACC-001");
    assertEquals(50000.00, acc.getAmount()); // renamed field
}

// Transfers Service unit test: PASSES
@Test
void transferUsesBalance() {
    // Mocks the accounts response
    when(accountsClient.getBalance("ACC-001"))
        .thenReturn(new BalanceResponse(50000.00)); // old shape
    // Test passes because the mock still returns the old shape
}

// BOTH pass. Interface is BROKEN.

Why are E2E tests insufficient at scale?

E2E tests catch the break but do not scale with the number of services.

  3 services:  3 pairwise E2E tests (manageable)
  10 services: 45 pairwise E2E tests (slow, flaky)
  50 services: 1225 pairwise E2E tests (impossible)

  And each E2E test needs ALL services running.
  Setup time, flakiness, and cost grow exponentially.

How does contract testing fill the gap?

Contract testing verifies the interface independently and fast, without standing up both services.

  Consumer test (runs alone):
  "I send GET /api/accounts/ACC-001/balance
   I expect: { accountId, balance (number), currency }"
  -> Generates pact file

  Provider verification (runs alone):
  "Replay each interaction from the pact
   Check actual response matches expected"
  -> FAILS if renamed field breaks the shape

  Both run in their own CI pipelines.
  No need to stand up both services together.

How does can-I-deploy work?

The Broker tracks which consumer and provider versions are compatible and gates deployment.

# Before deploying AccountsService v2
pact-broker can-i-deploy \
  --pacticipant=AccountsService \
  --version=v2 \
  --to-environment=production

# Output: CANNOT DEPLOY
# Reason: TransfersService v1.5 depends on field 'balance'
#         which is missing in AccountsService v2

# The deployment is blocked. Fix before shipping.

How does it enable safe independent deployment?

With contract testing, each team can deploy confidently and frequently.

  Without contract testing:
  "We need to coordinate every release with every consumer team."
  -> Slow, manual, error-prone

  With contract testing:
  "If can-I-deploy passes, we know we are not breaking anyone."
  "If we need to change a field, we do expand-and-contract:
   support both old and new shapes during the transition."
  -> Fast, automated, safe

How do you handle breaking changes?

Use expand-and-contract: the provider supports old and new shapes during the transition.

// Step 1: Provider returns BOTH old and new field names
public class BalanceResponse {
    private String accountId;
    private double balance;  // old name (kept for consumers)
    private double amount;   // new name (for new consumers)
    // Both are populated during the transition
}

// Step 2: Consumers migrate to the new field name
// Step 3: Provider removes the old field
// Contract tests ensure no consumer is broken at each step

What does contract testing complement?

Contract testing does not replace other testing; it fills a specific gap.

| Testing Type | What It Catches |
|---|---|
| Unit tests | Internal logic bugs |
| Contract tests | Interface drift between services |
| Integration tests | Component interaction bugs |
| E2E tests | End-to-end business flow bugs |

What are common interview follow-up questions?

• "Can contract tests catch a business logic bug?" No. They test structure, not behavior. Business logic is tested in unit and integration tests.
• "What if a consumer does not write contracts?" The provider does not know what it relies on, so breaking changes are not caught. Consumer participation is essential.
• "How many consumers can a provider support?" Unlimited. The Broker tracks all pacts and the provider verifies against all of them.