Implement Contract Testing with Pact

This skill is an expert in contract testing with the Pact framework for consumer-driven contract testing in microservice architectures - Pact implementations across languages, broker configuration, CI/CD integration, and advanced testing patterns. Core principle: consumers define expected interactions through executable specifications, contracts are generated from consumer test runs (never written manually), and testing focuses on integration points, verifying only what the consumer actually uses from the provider. The Pact process runs in five steps: the consumer writes tests defining expected interactions, Pact files are generated from running those tests, contracts are published to a Pact Broker, the provider verifies the contracts against its real implementation, and results are published back to the broker's compatibility matrix.

Use it when two services need to verify their API integration stays compatible across independent deployments, without standing up full end-to-end integration tests.

const provider = new PactV3({
  consumer: 'user-web-client',
  provider: 'user-api',
  port: 1234
});

await provider
  .given('user with ID 123 exists')
  .uponReceiving('a request for user 123')
  .withRequest({ method: 'GET', path: '/users/123' })
  .willRespondWith({
    status: 200,
    body: { id: integer(123), name: like('John Doe') }
  });

Consumer test patterns are shown for JavaScript/Node.js (@pact-foundation/pact with PactV3 and matchers) and Java (@Pact/PactDslWithProvider with JUnit 5). Provider verification is shown wiring a Verifier against a running app instance, with state-change handlers to set up fixture data per interaction and a request filter to inject auth headers, publishing results to the broker with a provider version and environment tags. Matching strategies range from type-based (integer, decimal, boolean, eachLike) to regex-based (email, phone, timestamp formats) to deeply nested structures. Broker CLI usage covers publishing pacts (pact-broker publish) and a can-i-deploy safety check before releasing to an environment, both wired into a GitHub Actions workflow that runs consumer tests, publishes contracts, then verifies and gates deployment on the provider side.

Versioning guidance calls for semantic versioning of contract participants, backward-compatibility checks, feature toggles for gradual API changes, and properly tagging deployments for environment tracking; maintenance guidance covers running contract tests in parallel, caching provider-state setup between tests, using webhooks for automatic provider verification, and regularly cleaning up old contract versions to keep the broker's compatibility matrix relevant.

Teams running microservices who need to catch breaking API changes between independently-deployed consumer and provider services before they reach production, using executable, consumer-generated contracts instead of manually maintained integration tests. Contract design guidance is explicit about scope discipline: test the interface rather than the implementation, use provider states that represent real business scenarios, keep contracts limited to what the consumer actually needs rather than exhaustively covering every possible API response, and maintain multiple contract versions during a transition when the API is evolving rather than breaking consumers outright.