API Contract Testing

A testing approach where API consumers define their expectations of the provider as a contract. The provider verifies it fulfils those expectations. Consumers drive the contract — they define exactly which endpoints and response shapes they need.

"The notifications service (consumer) defines a contract: 'I call GET /users/{id} and expect { id, email, notification_preferences }.' The user service (provider) runs the contract verification in CI: it calls its own API with the consumer's request and verifies the response matches the expectation. If the user service drops email from the response, the consumer's contract test catches it before deployment."

A JSON file generated by the consumer test run, capturing the interactions: the requests the consumer makes and the responses it expects. Published to the Pact Broker. The provider downloads it and verifies each interaction.

"After the consumer test run, a pact file is generated: { 'consumer': 'order-service', 'provider': 'inventory-service', 'interactions': [{ 'request': { 'method': 'GET', 'path': '/items/42' }, 'response': { 'status': 200, 'body': { 'id': 42, 'inStock': true } } }] }. This pact file is the contract."

A named precondition that the provider sets up before verifying a specific interaction. Ensures the provider's database is in the state expected by the consumer's test (e.g., 'user 42 exists and is active').

"The consumer test has provider state: 'user 42 exists.' Before verifying the interaction, the provider test framework calls the provider's state setup endpoint: POST /pact/provider-states with body { state: 'user 42 exists' }. The endpoint seeds the test database. Without provider states, interactions requiring specific data would fail with 404 or inconsistent results."

A service for storing and sharing pact files between consumer and provider teams. Consumers publish pacts after test runs; providers download them for verification. The Pact Broker also stores verification results and powers can-i-deploy checks.

"Our Pact Broker (PactFlow) is the contract registry: consumers publish pacts after successful consumer test runs (pact publish --consumer-app-version $GIT_SHA). Providers fetch the latest pact for each consumer (pact verify) and publish verification results. The broker's visualisation shows the contract compatibility matrix across all service versions."

A Pact CLI command that queries the Pact Broker to determine if a specific version of a service is safe to deploy — all its contracts with other services are verified compatible. Integrates into CD pipelines as a deployment gate.

"Before deploying user-service v2.3.1 to production, CI runs: pact-broker can-i-deploy --pacticipant user-service --version 2.3.1 --to production. The Pact Broker checks: does v2.3.1 have verified pacts with all its current production consumers? If any consumer contract is unverified or fails, can-i-deploy exits 1 and blocks the deployment."

An approach where the API contract (OpenAPI spec, Pact interactions, Protobuf definition) is defined before implementation. Consumers mock against the contract; providers implement against it. Enables parallel development without a running service.

"We define the OpenAPI spec first in a shared repo. Both teams review and sign off. The frontend team generates a mock server from the spec and develops the UI immediately. The backend team implements against the spec. Integration testing uses contract verification. No 'the API changed and no one told us' surprises at integration time."

The process of the provider running the consumer's pact interactions against its own implementation. Each interaction is replayed: the provider receives the consumer's request and its response is validated against the consumer's expectation.

"Provider verification runs in CI on every PR to the inventory-service. It fetches pacts from all registered consumers (order-service, cart-service, reporting-service) and replays each interaction. If inventory-service changes the item schema, the reporting-service's contract fails verification — blocking the PR merge before any services are deployed."