contract-testing

Write a consumer test that defines expected interactions using provider.addInteraction with request and response details, then run it against Pact's mock server. This generates a JSON contract file that the provider later verifies against its real implementation.

Contract tests verify API boundaries between two services using mocks, running in seconds without deployment. End-to-end tests deploy the full system and test through the UI, which is slower, flakier, and gives later feedback.

Consumers publish contracts to the Pact Broker, and providers verify against all consumer contracts in CI. The can-i-deploy command checks verification results before production deployment and fails the build if any consumer contract is broken.

Provider states are named preconditions like 'user 123 exists' that the consumer declares in its contract. The provider implements state handlers that set up required test data, such as inserting database records, before each verification runs.

Use matchers like like(), eachLike(), and term() instead of exact values. Type-based matching keeps contracts flexible so providers can return different valid values without breaking verification, while exact matching creates brittle tests.

Contract tests do not replace integration or end-to-end tests because they verify API shape, not business logic across services. They also add overhead for single-team monoliths where services are not independently deployed.