# Senior testing playbook

Compressed reference for the senior-only testing extension. Pair with [cheat-sheet.md](./cheat-sheet.md), [GLOSSARY.md](./GLOSSARY.md), and [repo-testing-map.md](./repo-testing-map.md).

## The senior shift
Intermediate understanding is: "I know the house test shape, testify mocks, the generators, `testutil.MockDB`, and how to run and cover the tests."

Senior understanding is: "I can explain why the suite is structured this way, choose the right layer and the right double, diagnose flakiness, and review tests for truthfulness rather than only greenness."

## Six senior lenses
1. **Strategy beats slogans** — choose the cheapest reliable layer for the bug class.
2. **Seams reveal design quality** — hard-to-test code often signals blurry boundaries.
3. **Flakes are evidence** — shared state, ordering, or timing is leaking into the test.
4. **Double choice is deliberate** — mocks, `MockDB`, and heavier collaborators each buy different proof.
5. **Review is about truthfulness** — ask what the test proves and where it could still lie.
6. **Repeatability is a design goal** — `-count=3` is not ceremony; it enforces determinism.

## Senior review checklist
- Can you explain why a test belongs at this layer instead of another one?
- Can you justify the chosen double as the cheapest honest proof?
- Can you spot happy-path-only coverage even when the file is green?
- Can you name the likely cause of a flaky repeated-run failure?
- Can you explain how seam pain points back to production design?
- Can you review a test for brittle expectations and false confidence?

## Interview answer shapes
### Why not just write more realistic tests?
Because realism costs time and determinism. Strong testing chooses the cheapest layer that can still prove the behavior honestly.

### Why does `-count=3` matter?
It exposes tests that depend on hidden state, order, or timing luck, so the suite must be repeatable rather than just occasionally green.

### Why are interfaces important here?
Because they create seams that let unit tests substitute collaborators honestly and keep orchestration testable.

### When is `testutil.MockDB` the right choice?
When repository query/scan behavior needs stronger proof than a plain mock but still should not pay for a real database.

### What is the real job of a senior test reviewer?
To ask what behavior the test proves, what it leaves unproven, and whether its assertions or expectations are too weak or too coupled.