Contract test
Both sides of an API test against a written agreement instead of each other, so the backend learns it broke the frontend without booting it.
See it
What it is
A contract test pins down the agreement between a consumer (the app calling an API) and a provider (the service answering), then lets each side verify itself without booting the other. The agreement covers more than field names: status codes, headers, required parameters, error payloads, and which interactions are legal at all.
Consumer-driven contracts are the best-known form. The consumer records what it sends and what it needs back, that recording becomes a file, and the provider replays those expectations against itself in its own CI, so it finds out the moment it renames a field somebody depends on. Pact is the canonical tool here, with a Pact Broker holding the contracts. The other direction is equally real: the provider publishes an OpenAPI or JSON Schema document and both sides validate against it, which is how most schema-driven and provider-driven setups work. Protobuf and Avro compatibility checks are the same idea wearing a different hat.
Reach for any of them when a separate team, a mobile app you cannot force to update, or three microservices depend on your endpoints. It buys you the confidence of a full integration environment for a fraction of the runtime.
Gotcha: a contract test proves compatibility, not correctness. A provider can return a perfectly shaped price that is wrong by a factor of 100 and every contract still passes. It is also worthless unless the provider actually runs the consumers' contracts on every build, which is the step teams quietly skip.
Ask AI for it
Set up consumer-driven contract testing with Pact between our web client and the orders service. On the consumer side, write pact tests for GET /orders and POST /orders that describe the request and the expected response body using matchers (types and regexes, not literal values), and publish the generated pact file with the git SHA as the version. On the provider side, add a verification task that fetches the pacts, replays them against the running service with provider states for 'orders exist' and 'no orders', and fails the build on any mismatch.