Contract Testing

The Integration Testing Wall

 naive approach: spin up ALL services, test flows end-to-end:

 [orders]+[inventory]+[payments]+[identity]+... in ONE env:
 - 15 services to boot/version/seed per test run
 - flakiness multiplies (any service's hiccup fails everything)
 - ownership blurs: whose test failed? whose fix?
 - environments drift from prod anyway → false confidence
 - CI time measured in hours; teams stop waiting

 CONTRACT TESTING replaces graph-wide tests with
 pairwise PROMISES verified independently.

How Contract Tests Work

 consumer-driven flow (pact-style):

 1. CONSUMER defines expectations:
    "GET /orders/42 with auth → 200 {id,total,status}"
    (the fields IT actually uses — nothing more)

 2. contract published to a BROKER.

 3. PROVIDER verifies: replays contract against ITS
    implementation → pass/fail per expectation.

 4. GATE: provider deploys blocked if it breaks any
    live consumer's contract ✓

 [consumer]──publishes──►[broker]◄──verifies──[provider]
                              │
                    can-i-deploy checks ✓

 each pair tested SEPARATELY, in each team's own CI,
 against MOCKS on one side — no shared environment needed.

What Contracts Catch (and don’t)

Caught by contracts	NOT their job
removed/renamed response fields	business-flow correctness
type/format changes	performance characteristics
status-code changes	full-system resilience
breaking enum removals	cross-3+-service choreography
semantic drift (documented!)	UI behavior

 the layering that works:
 unit tests (logic) → contract tests (boundaries) →
 a FEW targeted end-to-end smoke tests (critical journeys) →
 production monitoring/chaos for everything else.
 contracts kill the NEED for sprawling E2E suites.

Operating Contract Testing Well

 □ CONSUMER-DRIVEN beats provider-guessing: contracts encode
   REAL usage, not imagined completeness
 □ BROKER as the integration marketplace: versioned pacts,
   verification results, can-i-deploy gates wired into CD
 □ STRICTNESS dial: match on USED fields only —
   over-specified contracts break on harmless additions
   and teams learn to game them
 □ EVENT contracts too: message schemas get pact-like
   verification (schema registry + consumer tests)
 □ BREAK GLASS: emergency provider hotfix bypassing a stale
   consumer contract = documented exception path, audited

Interview Framing

“40 services, integration test suite takes 3 hours and flakes constantly” scored diagnosis: E2E-graph-testing anti-pattern named, contract-testing architecture explained (consumer-driven + broker + deploy gates), layered-test-pyramid placement shown, event-contract extension mentioned, strictness-balance warning included. This question appears wherever microservice estates grow past ~a dozen services — the answer demonstrates whether your testing STRATEGY matches your architecture or fights it.