A provider's build goes red because a consumer team added a new expectation to its contract before the provider implemented it. The provider team wants to delete contract testing. What mechanism fixes this specific failure, and what does the full gate cost to run?

What is gained

The provider's build going red for a consumer's unimplemented wish is the single most common reason contract testing gets abandoned, and it is a configuration problem rather than a flaw in the idea.

Pending pacts fix it directly: with the feature enabled, a provider's verification fails the build only for contracts the provider was already known to support. A brand-new expectation is verified, reported and does not break the build. The related WIP pacts mechanism lets the provider verify a consumer's feature-branch contract in pending mode, so the consumer gets feedback while the provider stays green. Both are documented features of the Pact broker, introduced in 2020, rather than a workaround.

The important asymmetry: pending does not make the consumer deployable. Its can-i-deploy check still fails, because the provider genuinely does not support what it needs. The red light moves to the team whose change is not yet safe, which is the whole point of the gate.

What the full arrangement buys is the ability to deploy either side without a shared staging environment: can-i-deploy answers "is the version I am about to ship compatible with what is actually running in that environment", which end-to-end tests in a staging environment answer only for whatever happened to be deployed there that afternoon.

What is paid

• A verification matrix. Every provider build verifies every consumer's contract for every environment of interest. With 12 consumers and 3 environments that is 36 verifications, which can add 10 to 20 minutes to a build, and the provider's build time grows with other teams' output — an unusual and unpopular property. Selective verification by deployed version is the mitigation, and it is extra configuration.
• Provider states. Each interaction needs the provider's data set up to match, and this remains the main implementation cost of contract testing. Provider states rot quietly as the provider's schema moves.
• A broker to run. Another service, with its own availability requirement, in the deployment path of every team. When it is down, nobody can answer can-i-deploy, so you need an explicit break-glass policy before the first time that happens.
• A discipline, not a tool. The gate only means something if deployments actually stop. The first time a release is waved through because the broker said no, the mechanism becomes decoration.

When the cost becomes visible

At about the point where you have more than a handful of consumers per provider and more than two environments, which is also the point where the mechanism starts paying for itself. Choose the gate once you pass roughly four or five consumer-provider pairs; below that a shared integration test and a conversation are cheaper, because the coordination the gate automates is coordination you can still do by talking.

How to keep the option to reverse

Keep contracts generated from consumer tests rather than hand-written, so they remain a by-product. Then abandoning the broker costs you the gate and not the tests. And record the provider-state setup as ordinary test fixtures in the provider's repository, so the investment survives a change of tooling.

When this is the wrong answer

Contract testing answers "do these two components agree on the message", and nothing else. It does not verify behaviour, performance, authorisation or the semantics behind a field, and teams that expect it to replace integration testing end up with both a false sense of safety and a slow build. For a provider with one consumer in the same repository, the type system already does this job and the broker is pure overhead.