When is consumer-driven contract testing with Pact and a shared Pact Broker not worth adopting, and what do you do instead?
answer
- List what the practice needs to work
- Someone must own the shared broker
- External consumers cannot be compelled
- A failure nobody blocks on is advisory
- Provider specification plus compatibility gate instead
basics
~20 sSkip it when consumers are unknown or external, when a provider team will not treat a red verification as blocking, or when nobody will operate the broker. Publish a provider specification and gate on a compatibility diff instead.
solid answer
~40 sThe practice needs four things to be true: the consumers are knowable, each consuming team will maintain a test, the provider's pipeline treats a failure as blocking, and someone owns the broker as real infrastructure. It stops paying when any of those is false. One team owning both services should write a direct integration test. Public or unenumerable consumers cannot be asked to publish expectations. A provider team that ignores red verifications turns recorded expectations into a wish list. An unowned broker fills with stale pacts until nobody trusts a verdict. Instead: publish a provider specification and gate releases on a compatibility diff, which covers every consumer including the ones you cannot name. Then pilot contract testing on one high-churn edge with two willing teams, and extend only where the preconditions hold.
go deeper
Recall that contract testing needs both teams to take part: one side records expectations and the other verifies them inside its own pipeline before releasing.
Name the preconditions in an interview: a knowable set of consumers, teams willing to maintain the tests, a provider pipeline that treats a failure as blocking, and an operated broker.
Argue a concrete case where you chose not to adopt it, say what you used instead, and state the residual risk you accepted rather than claiming the alternative was equivalent.
Own the rollout strategy: which edges get behavioural evidence, who funds and operates the broker, and how you stop a half-adopted estate from trusting verdicts that cover pairs nobody can list.
## What the practice actually requires Consumer-driven contract testing is usually presented as a tooling choice. It is an organisational arrangement with tooling attached, and it needs five things to be true at once. Judging adoption means checking them honestly rather than counting features. 1. **The consumers are knowable.** You can enumerate who calls this interface. If you cannot, recorded expectations cover an unknown fraction of real usage and you will not know which fraction. 2. **Every consuming team will write and maintain tests.** Not once, at adoption; continuously, including when the interface changes and nobody feels like updating a test for someone else's service. 3. **The provider's pipeline treats a failure as blocking.** A red verification that does not stop a release is a notification, and notifications are ignored on a schedule. 4. **Someone owns the broker as production infrastructure.** It is patched, backed up, pruned of dead pacticipant versions, and its access is managed. An unowned broker becomes a graveyard whose verdicts nobody believes. 5. **The interface changes often enough to be worth the ceremony.** Contract testing pays for itself in prevented breakages. A stable interface produces very few. ## Where it stops paying | Situation | Why the practice fails there | What to do instead | | --- | --- | --- | | Two services, one team, one repository | The coordination problem the practice solves does not exist | A direct integration test across the two components | | Public or third-party consumers | You cannot require an external client to publish expectations | Publish a provider specification and gate releases on a compatibility diff | | Consumers you cannot enumerate | Coverage is unknown and unknowable | Compatibility gating, plus access logs to learn who actually calls what | | A provider team that will not act on red | Recorded expectations become a wish list | Fix the agreement first, or drop to producer-first stubs and be honest about the guarantee | | Nobody owns the broker | Stale pacts and unverified versions poison the verdicts | Do not adopt until an owner exists; a hosted broker moves the operations, not the ownership | | A stable, rarely changing interface | Little churn, therefore little prevented breakage | Specification diff on release, and spend the effort elsewhere | The row that costs the most in practice is the provider one. On a 23-service marina berth-allocation estate, the tide-and-tariff feed was owned by a provider team in another timezone with its own roadmap. Pacts were published for it for four months. Verification ran, went red 9 times, and never once blocked a release, because nobody in that timezone had agreed that it should. The pacts were not wrong; they were unenforced, and an unenforced contract test is a maintained artefact producing no safety at all. The fix was not more tooling. It was an explicit agreement on the blocking gate, which took one conversation that should have happened before the first pact was published. ## The judgement to demonstrate Two failure modes bracket the decision, and a senior answer names both. - **Adopting where the preconditions are false** produces the worst outcome available: the cost of writing and maintaining tests, plus the operational cost of a broker, plus false confidence, because teams delete end-to-end scenarios on the strength of verdicts nobody enforces. - **Refusing to adopt anywhere** leaves independently deployed services with only end-to-end testing to catch integration breakage, which is the slow, flaky arrangement the practice exists to replace. The route between them is a pilot rather than a programme. Pick one high-churn edge with two willing teams, run it end to end including the blocking gate, and measure two numbers: how many end-to-end scenarios it retired, and how many real breakages it caught before a release. Then extend edge by edge, deliberately leaving edges uncovered where the preconditions do not hold, and using provider-published specifications with compatibility gating there instead. ## What to say about a half-adopted estate A partially adopted estate is the normal end state, not a failure, and the risk is not the uncovered edges. It is that people forget which edges are covered. Record the choice per interface: this pair has behavioural evidence, that pair has a specification gate and no behavioural evidence, this third one has an end-to-end journey because it has neither. Publish that list where the teams deleting tests can read it. The estate that gets hurt is the one where everyone believes contract testing is switched on, and nobody can say for which pairs.
- What is the smallest useful pilot for consumer-driven contract testing across an estate?One high-churn edge, one consumer, one provider, both teams willing, the broker in CI, and the provider's verification job actually blocking its release. Run it for a few release cycles and measure two things: how many end-to-end scenarios it let you retire, and how many real breakages it caught before a deploy. Those two numbers, not enthusiasm, decide whether you extend.
- How do you decide whether operating a shared Pact Broker is worth it?Treat it as production infrastructure and name its owner before adopting. Someone patches it, manages access, and prunes stale application versions and dead pacticipants, or the matrix fills with noise and verdicts stop meaning anything. A hosted broker shifts the operational work but not the ownership question: if no team will own the data and the pruning, the practice will decay wherever it is hosted.
- An internal consumer team refuses to write pacts. What do you do?Accept that the provider cannot be verified against expectations that do not exist, and stop pretending otherwise. Either the provider publishes a specification and gates on compatibility, which covers that consumer without their participation, or you keep the end-to-end scenario for that edge as the only evidence. What you must not do is write a pact on their behalf and treat a guess as a recorded requirement.
Consumer-driven contract testing is a mutual insurance scheme. It only pays out while every member keeps contributing, and a member who stops still expects to be covered.
saying these in an interview costs you the question
- Rolls contract testing out estate-wide before any pilot
- Assumes external consumers can be told to write pacts
- Treats the broker as a toy nobody has to operate
- Keeps publishing pacts a provider never verifies
- Adopts it where one team owns both services
- Cannot say which pairs actually have behavioural evidence