api-contract-testing

Use PactV3 from @pact-foundation/pact to define the consumer and provider, then chain given, uponReceiving, withRequest, and willRespondWith to describe the interaction. Use MatchersV3 like string, email, and like for flexible response matching, and run assertions inside executeTest against the mock server.

Consumer-driven contract testing lets the consuming service define the request/response format it expects, and the provider verifies it satisfies those contracts. Tools like Pact record interactions as contract files, publish them to a broker, and verify providers without running full integration environments.

Use the jsonschema library with pytest: define schemas as dictionaries with required fields, types, formats, and enums, then call validate with the response JSON. Wrap validation in a helper class returning a boolean and error message, and use mocked responses for faster unit tests.

Consumers publish contracts to the Pact Broker after tests pass, and providers verify against them in their own pipeline, publishing verification results. The can-i-deploy command checks compatibility before release, and broker webhooks can trigger provider verification via GitHub repository_dispatch events when contracts change.

Contract tests should not cover business logic, hard-coded specific values, or internal implementation details. They validate structure and response shape using matchers, cover error responses like 404s, and check backward compatibility rather than duplicating functional test coverage.