Engineering Practice
Contract testing: multiple-choice review
Crux Multiple-choice synthesis across the contract-testing unit — why e2e collapses, consumer-driven recording, provider verification, the deploy gate, and the hard limits.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a decision you actually make on a platform of services that deploy independently — not a definition to recite, but a tradeoff to weigh under real coupling.
Goal
Confirm you can connect the failure of e2e at scale, consumer-driven recording, provider verification, the can-i-deploy gate, and the limits — the synthesis the individual lessons built toward.
Quiz
Completed
Why does a shared end-to-end environment's reliability degrade as a platform adds services, and what does that imply about the fix?
Heads-up Service age isn't the driver. Even at 98% green each, stringing twelve together drops the journey below 80% because the probabilities multiply — the structure, not bug count, is the problem.
Heads-up Resource limits are a separate, fixable concern. Parallelism doesn't change the N² shape — you still need one shared environment green all at once. That's the trap teams fall into right before they look for something better.
Heads-up Test length isn't the cause. The fragility is the runtime requirement that all services be healthy at the same instant — multiplying uptimes — not how much test code you wrote.
Quiz
Completed
A provider returns 40 fields; a consumer reads 4. Why is recording only those 4 (matched by type) the right scope for a consumer-driven contract?
Heads-up Recording all 40 makes the contract a brittle snapshot that fails on benign value changes and on fields no one reads, generating the noise that gets it muted — the same trust-erosion that killed the team's OpenAPI doc.
Heads-up Existence-only lets the provider switch a number to a string and slip past the gate, so real breakage leaks through. The consumer parses these as a type, so the type is exactly what must be asserted.
Heads-up The provider's spec flags every change equally, can drift from the code, and doesn't know which fields anyone depends on — the noisy, rot-prone model consumer-driven contracts exist to replace.
Quiz
Completed
During provider verification, the provider adds three new fields to a response the consumer's pact never mentions, but also renames one field the consumer reads. What is the verification outcome?
Heads-up Provider verification is not an exact match. It asserts the actual response contains at least the minimal expected shape; extra fields are explicitly allowed, which is what lets the provider evolve fields no consumer reads.
Heads-up Field count is irrelevant. The minimal-response check looks for each field the consumer asserted; a renamed consumed field is simply absent under its old name, so that interaction fails regardless of additions.
Heads-up A shape change never skips verification — it triggers the comparison. Verification fails precisely when a field the consumer reads is missing or retyped, which is what the rename does.
Quiz
Completed
An interaction's `given` is 'a price with id 42 exists', but the provider team never wrote a handler for that state. Verification fails. How should a senior read this failure?
Heads-up The request and expected response are valid. The failure is a missing provider-side state handler for a `given` string — changing the pact would only paper over real, useful coverage.
Heads-up Provider states are the precondition the interaction depends on. Without a handler the data isn't seeded, so the replayed request can't produce the expected response — they're never ignored.
Heads-up The verifier doesn't write the provider's data store from pact examples — those describe the expected response shape, not seed data. The provider must register a handler that sets up the data.
Quiz
Completed
A consumer's new pact is verified green against the provider's latest CI build, the pipeline is all green, so it deploys — and prod errors immediately. What was the wrong question, and what asks the right one?
Heads-up Results don't expire on a timer. The problem is which provider version the result is about — green against latest says nothing about the older build physically serving prod traffic.
Heads-up One verification of the correct pair is conclusive. The issue is the count of versions, not runs: the verified pair (new consumer, latest provider) isn't the pair created at deploy time (new consumer, deployed provider).
Heads-up Versioning by git SHA matters because the version must change when the contract could — a bare semver can label two different contracts. But the actual gap here is checking against deployed vs latest, which only can-i-deploy does.
Quiz
Completed
Every contract passes, yet the provider returned a structurally-perfect `amount_cents: -500` for a refund and checkout charged a negative balance. What does this reveal about contract testing's place in the strategy?
Heads-up No matcher catches this in general — a type matcher asserts amount_cents is an integer, and -500 is a valid integer. Matchers guard structure, not business correctness; this is a categorical limit, not a config bug.
Heads-up BDCT compares pact against spec — still pure shape and type checking, no value semantics. It passes -500 just as readily. Catching it needs a test that asserts business rules, i.e. e2e or unit logic.
Heads-up Contracts correctly retire most flaky cross-service e2e for known internal pairs. The lesson is proportion — many contracts, a few e2e smoke tests — not abandoning contracts because they can't see semantics.
Recap
The unit’s through-line is one pipeline of decisions: e2e collapses because a shared environment’s health is the product of every service’s uptime, so push compatibility down to a per-edge test; the consumer records actual usage by type into a pact; the provider verifies by replaying each interaction against the real service, checking the minimal expected shape with provider states seeding the data; can-i-deploy turns the verification matrix into a deploy gate by crossing your git-SHA version against what’s actually deployed; and the hard limit — contracts test shape, never semantics — is why a thin layer of real e2e smoke tests survives. Every wrong answer here is a real team’s wrong turn.