Contract Testing
Also known as: consumer-driven contracts, Pact testing
Contract testing verifies that a provider's API satisfies the expectations its consumers actually rely on, by running each consumer's recorded expectations against the provider in isolation. It catches integration breakage without an end-to-end environment containing every service.
Last reviewed · Part of the Architecture Glossary
In practice
The consumer-driven flow (Pact and similar):
- The consumer's tests run against a mock provider and record the requests made and responses expected.
- That pact is published to a broker.
- The provider's pipeline replays every consumer pact against the real provider.
- A provider change that breaks any consumer fails the provider's build — before merge, not in a shared environment two weeks later.
Why it beats the alternatives: end-to-end suites over ten services are slow, flaky and require an environment nobody can keep healthy; schema validation alone proves the response parses, not that the field a consumer depends on still carries meaning. A contract encodes actual usage, which is also documentation of who depends on what.
can-i-deploy is the piece that turns it into a gate — the provider asks the broker whether the version it wants to deploy is compatible with what is currently in production for every consumer.
When it matters
Independently deployed services with more than a couple of consumers, public APIs with versioning commitments, and any team trying to delete a shared staging environment.
Common mistake
Writing contracts that assert the entire response body. The provider then cannot add a field without breaking every consumer — the opposite of what the practice is for. Assert only the fields the consumer actually reads.
See also
- CouplingCoupling is the degree to which one component depends on the internals of another, measured by how much of it must change when the other changes.
- Fitness FunctionAn architectural fitness function is an automated, objective test of a non-functional requirement — coupling, latency, security posture, cost — run continuously in CI.
- Trunk-Based DevelopmentTrunk-based development is the practice of integrating every change into a single shared branch at least daily, with short-lived branches measured in hours.