On this page5 sections
ReferenceAdvanced5-7 min reference

Pact

Pact is the most common consumer-driven contract testing tool. The consumer's tests generate a pact file; the provider replays it to prove it still honours the agreement. This is a fast reference for the workflow and CLI; for the underlying concepts see the Contract Testing Terms sheet, and for starter configs see the Configs library — both linked below.

The workflow

  1. Consumer test defines expected interactions → produces a *.pact.json file.
  2. The pact is published to a Pact Broker (tagged with the consumer version + branch).
  3. Provider runs verification: replays each interaction against the real provider.
  4. Verification results are published back to the broker.
  5. can-i-deploy checks both sides are compatible before release.

Key terms

TermMeans
Pact fileJSON contract generated by the consumer
Mock providerStub the consumer tests against
Provider statePrecondition set up before an interaction ("user 1 exists")
MatcherMatch by type/regex, not exact value (like, eachLike, term)
BrokerStores + shares pacts, tracks verification
VerificationProvider replaying the contract

Commands you'll see

CommandDoes
pact-broker publish ./pacts --consumer-app-version=$SHAPublish contracts
pact-broker can-i-deploy --pacticipant App --version $SHA --to-environment productionRelease gate
pact-broker create-version-tagTag a version (branch/env)
provider test task (per language)Run provider verification

When to use

Microservices with independent deploys where you need pre-deploy integration confidence. Use matchers, not exact values, so contracts don't break on dynamic data.

Common mistakes

  • Asserting exact values instead of matchers → flaky contracts on timestamps/ids.
  • Forgetting provider states, so verification can't set up its preconditions.
  • Skipping can-i-deploy, which defeats the point — you deploy incompatible versions.
  • Treating Pact as functional testing; it checks the contract, not the business logic.