Understanding Pact contracts
Consumer-driven contracts — the integration test that doesn't need both services.
What a Pact file looks like, why the consumer writes the contract, and how the broker keeps the cycle honest.
The problem.
Service A calls Service B. The integration test that proves the call works needs both services running, plus their dependencies. The test is slow, flaky, and a pain to wire up in CI. Run it less often → bugs sneak in. Run it more often → CI slows down. The traditional answer (full-stack staging environments) is expensive; the modern answer (contract testing) lets each side test independently.
Consumer-driven.
Pact flips the contract authoring. The consumer service writes a test that says "when I make this request, I expect this response". Pact records the interaction as a JSON file (the "pact"). The consumer's tests run against a mock server that replays the pact. Separately, the provider's tests run the real service against the pact and verify each interaction. Neither side needs the other up at test time.
The pact file.
A pact file is JSON: a list of interactions, each with a request (method, path, headers, body) and an expected response (status, headers, body). Matchers can be loose — "any integer" instead of "exactly 42" — so the provider isn't forced to return identical data. The file is checked into the consumer repo, then published to a "broker" — a shared service that both sides read from.
The broker.
Pact Broker (or Pactflow, the hosted version) is the rendezvous point. The consumer publishes pacts after green tests. The provider verifies pacts against deployed versions. The broker records the verification status, the versions, and the "can-i-deploy" matrix — a query that answers "is provider v2 compatible with consumer v5?" The answer comes from real test runs, not human review.
A worked cycle.
Consumer-side test: mock.given("user 42 exists").uponReceiving("a request for user 42").withRequest(GET, "/users/42").willRespondWith(200, { "id": 42, "name":
like("Alice") }). Run; passes; pact published. Provider-side: pact-verifier fetches the pact, sets up the "user 42 exists" state via a provider state hook, replays the request, checks the response shape. Verification result back to broker. Either side can deploy when the broker says yes.
GET /users/42
consumer test + provider verify
One interaction, two test runs, broker mediates.
consumer pass + provider verify pass = can-i-deploy
= No staging required
When Pact is the wrong answer.
Public APIs with unknown consumers — you don't have their tests. Massive fan-out — Pact scales linearly with consumer count, and 50 consumers means 50 pacts to verify on every provider change. Highly dynamic responses — matchers help but extreme variability degrades to "it returned a 200, sure". For internal micro-services with a fixed set of known consumers, Pact is excellent; outside that, mind the limits.