Keep mocks from proving their own assumptions

What This Concept Is

A test double is a controlled substitute with a stated contract. It is useful for exploring failures but cannot verify that the real dependency obeys that contract.

Why It Matters Here

The walking skeleton includes a real datastore and observable request path precisely to expose integration assumptions that unit tests omit.

Concrete Example

A mock returns duplicate messages in order; the real broker can redeliver after a crash and reorder across partitions. Keep unit tests for local transitions, contract tests for adapter assumptions and an integration crash-cut test for persistence/delivery behavior. Record unsupported broker modes instead of generalizing.

Common Confusion / Misconception

More end-to-end tests are not automatically better. Slow redundant checks can obscure the one contract that matters. Conversely, an all-mock suite cannot establish database uniqueness or transaction isolation.

How To Use It

For each risk, choose the cheapest test that observes the relevant boundary. Retain at least one real end-to-end vertical slice. Remove duplicate checks only when the remaining evidence still covers the risk.

Check Yourself

Which claim requires actual storage? Which external behavior is assumed? What would falsify the mock contract?

Mini Drill or Application

Review the risk matrix and mark every mock boundary. Choose the riskiest one for an actual integration experiment and revise the claim if behavior differs.

Read This Only If Stuck

Building Secure and Reliable Systems provides selective operational reasoning. Use the module sources below for current tool behavior; do not read a whole book before attempting the exercise.

SRE testing chapter; Google code review. Prior semester testing and concurrency labs remain the backbone.