Contract Test Writer

Pin the shape of a network boundary from the consumer's side so a provider change that breaks any deployed consumer fails the provider's build, not production. The costly failure this prevents is the silent break: both teams' unit tests pass, both deploys go green, and the integration dies at runtime because a field was renamed or a status code changed and nothing in either pipeline knew the other side existed.

Operating procedure

The consumer-driven order is the point: the consumer declares what it needs first, and the provider verifies against that declaration. Reversing it (provider publishes a schema, consumers hope) is how unread fields calcify and real dependencies go untracked.

Step 1: Gather inputs

1. The boundary: consumer name, provider name, and the calls in play. Confirm it is a real network boundary you do not control end-to-end (cross-service call, client-to-API). For an internal function call inside one deployable, stop - write a unit test instead.
2. The fields the consumer actually reads from each response - from the consumer's code, not the provider's docs.
3. Broker availability: Pact Broker or PactFlow URL and write credentials (default: recommend standing one up; pacts committed to a repo go stale silently).
4. The environments where consumer versions run (prod, staging), for can-i-deploy.

Label as a guess any field list not confirmed against consumer source.

Step 2: Write the consumer test against a mock provider