Contract Testing
Verifying that a service and its consumer agree on an interface's shape, without either side needing the other running to test against.
Contract testing verifies that two independently deployed services — a provider (an API) and a consumer (whatever calls it) — agree on the shape of the interface between them, without requiring either side to run the other live during the test. The consumer records or declares a "contract" describing what it expects to send and receive; the provider is then tested against that same contract independently, on its own schedule, to confirm it still honors it. Neither side needs a working instance of the other in its test environment, which is the whole appeal in a microservice architecture where spinning up every dependent service just to test one integration point doesn't scale.
This sits in a specific gap between Unit Test and Integration Test. A unit test of the consumer, mocking the provider's response, proves the consumer handles a given response shape correctly, but proves nothing about whether the real provider actually returns that shape. A full integration test against a live provider proves the real behavior, but costs a live environment and couples the two teams' test runs together. Contract testing is the compromise: each side is tested against a shared, versioned specification instead of against each other directly, so a provider team can change their API and immediately learn — via automated contract verification in their own CI — whether that change would have broken any consumer's declared expectations.
Consumer-driven contract testing (the flavor Pact popularized) inverts the usual API-first process: consumers generate the contracts from what they actually use, and providers verify against the union of all consumers' contracts, which surfaces unused fields and unnecessary coupling that a provider-authored spec wouldn't reveal on its own. The tradeoff against a full Integration Test suite is coverage: contract testing catches interface-shape drift cheaply but says nothing about end-to-end behavior across the whole system, which is why the two are complementary rather than substitutes.
See also7
Snapshot Testing
Comparing a component or output's current rendering against a saved baseline, flagging any difference for a human to accept or reject.
Testing & Verification8 connections
Test Double
A stand-in for a real dependency during a test — and the ways a stand-in can lie.
Testing & Verification18 connections
Schema Drift
Divergence between a schema and the code, types, or documentation that describe it.
Data & Content16 connections
Service Virtualization
Replacing a real external service with a simulated one that speaks the same protocol over the network, so tests can run without the real dependency and can reproduce its failures on demand.
Testing & Verification15 connections
OpenAPI
A standard, machine-readable format for describing HTTP APIs, listing every endpoint, parameter, and response shape, from which tools generate documentation, client libraries, mock servers, and tests.
Web Platform11 connections
Record and Replay
Capturing real network responses once and replaying them in later test runs, which makes tests fast and deterministic but lets the recordings drift from the real service.
Testing & Verification11 connections
Schema Evolution
Changing the shape of stored or transmitted data without breaking the old readers and writers that still expect the previous shape.
Data & Content9 connections
Linked from7
- Design by ContractTesting & Verification
Specifying what each function requires and guarantees, as checkable preconditions, postconditions, and invariants, so a violation says exactly whose bug it is.
- End-to-End TestTesting & Verification
A test that drives the whole running system the way a user would, from the interface down through every real dependency, buying the most confidence at the highest cost.
- Integration TestTesting & Verification
A test exercising several components together, through real interfaces rather than doubles.
- OpenAPIWeb Platform
A standard, machine-readable format for describing HTTP APIs, listing every endpoint, parameter, and response shape, from which tools generate documentation, client libraries, mock servers, and tests.
- Record and ReplayTesting & Verification
Capturing real network responses once and replaying them in later test runs, which makes tests fast and deterministic but lets the recordings drift from the real service.
- Schema EvolutionData & Content
Changing the shape of stored or transmitted data without breaking the old readers and writers that still expect the previous shape.
- Service VirtualizationTesting & Verification
Replacing a real external service with a simulated one that speaks the same protocol over the network, so tests can run without the real dependency and can reproduce its failures on demand.