Contract testing validates communication agreements between services without requiring end-to-end integration, focusing on the interface expectations that consumers define and providers verify. Unlike integration testing which confirms full workflows across live services, contract testing isolates each service boundary and checks whether both sides agree on request/response structures, message formats, and interaction semantics. The approach gained traction with microservices architectures where teams own independent services and deploy continuously—breaking changes become expensive and hard to catch without a dedicated interface validation strategy. A well-implemented contract testing practice enables teams to deploy independently with confidence, reduces reliance on slow end-to-end tests, and catches integration mismatches early in the CI pipeline before they reach production.
What This Cheat Sheet Covers
This topic spans 15 focused tables and 116 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Core Concepts and Approaches
| Concept | Example | Description |
|---|---|---|
Consumer defines expected requests/responses in tests → generates contract file → provider verifies against it | • Consumers specify their expectations first • provider must satisfy all consumer contracts rather than dictating the API unilaterally | |
Provider publishes OpenAPI or contract spec → consumers generate clients or validate against it | • Provider defines contract (often OpenAPI/Swagger) • consumers adapt to the published specification | |
Provider publishes OpenAPI spec → consumer publishes own contract → broker verifies compatibility | • Each side maintains its own contract artifact • broker performs static cross-validation without consumer/provider needing direct coordination | |
JSON file with consumer/provider names + interaction array + metadata | • Language-agnostic contract artifact generated from consumer tests • contains all expected interactions with matchers and provider states | |
{ "description": "get user by ID", "request": {...}, "response": {...} } | • Single request/response or message exchange defined in a contract • provider must satisfy every interaction during verification |