Engineering Practice
Contract testing: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the mechanism stick.
Reconstruct the unit’s spine — why e2e collapses, how a pact is produced, what provider verification proves, what can-i-deploy adds, how to evolve a contract, and where contracts stop — without looking back at the lessons.
- 01Why does end-to-end integration testing collapse at scale, and where exactly does the test pyramid leave a hole that a field rename slips through?
- 02Walk through how a consumer-driven pact file is produced, and why that makes it more trustworthy than a hand-kept OpenAPI doc.
- 03What does provider verification actually do, including the minimal-response comparison and the role of provider states?
- 04Why is a green verification not enough to deploy, and what does can-i-deploy check instead? Why version by git SHA and record deployments at rollout end?
- 05How do you ship a breaking provider change without breaking consumers, and how do pending/WIP pacts handle the mirror, consumer-led case?
- 06State the hard limits of contract testing and the senior judgment call about contracts versus end-to-end tests.
If you could reconstruct each answer from memory, you hold the unit’s spine: e2e collapses because shared-environment health is the product of every service’s uptime, so push compatibility to a per-edge layer; a pact is a recording of passing consumer code matched by type, trustworthy where a doc rots; provider verification replays each interaction against the real service and checks the minimal shape with state handlers seeding the data; can-i-deploy crosses your git-SHA version against what’s actually deployed; expand-then-contract plus pending/WIP pacts evolve contracts without lockstep; and the limits — shape not semantics, known consumers only, real overhead, fixture-vs-production drift — are why a thin layer of real e2e smoke tests always survives.