Contract testing

Contract testing checks the agreement between a consumer and a provider rather than the behaviour of either one. The consumer declares what it sends and what it needs back; that expectation is recorded as a contract; and the provider verifies against the contract in its own pipeline. Neither side has to stand up the other to get an answer. The question being asked is narrow and precise: has one party changed something the other depends on?

It addresses the specific weakness of the two alternatives. Mocked integration tests are fast and pass forever, including for the eighteen months after the real API changed its response shape. Full end-to-end environments detect the breakage honestly but need every service deployed together, take a long time, and fail for reasons unconnected to the interface under examination. Contract tests keep the isolation of the first approach and the truthfulness of the second, at the cost of a shared artefact both teams have to maintain.

What it needs to work

• Verification running in the provider’s pipeline. A contract nobody checks on the provider side is documentation, and it will be wrong within a release or two.
• Contracts describing only what the consumer genuinely uses, since asserting on every field turns a harmless additive change into a build failure for a team that had no reason to expect one.
• A shared place to publish and retrieve them, with versioning, so a provider can see which consumer versions are still in production and which contracts it must satisfy.
• Organisational agreement about what happens on failure. The technical mechanism is straightforward; the hard part is two teams accepting that one of them is now blocked.

A contract test proves the shape of the exchange is intact, not that the provider’s logic is correct — it replaces the integration environment, never the provider’s own tests.