test-planlisted

Before writing code (or before a PR ships), name the cases that must pass — and the *level* they should live at. Picking the wrong level catches bugs but wastes weeks maintaining flaky fake tests. ## Example prompts - "Write a test plan for the auth middleware change" - "What should I test before merging this?" - "Plan the tests for the checkout retry logic" - "Test plan for the new /users route" ## Process 1. **Restate the change** in one sentence. "This adds X so that Y." If you can't state it clearly, the code isn't ready to test yet. 2. **List the cases** in three groups. Aim for 3–8 total cases, not 30. Coverage over completeness. - **Happy path** (1–2 cases): the normal expected use. Prove the feature does the thing. - **Failure modes** (2–4 cases): each *distinct* failure the user or system can trigger. Bad input, missing auth, downstream unavailable, race, timeout. Not every permutation — the *distinct* ones. - **Regressions to guard** (0–2 cases): existing behavior that this change is at risk of breaking. Only include if the change touches shared code. 3. **For each case, name the concrete assertion.** "It rejects a request with no token → returns 401 with `{ error: 'unauthorized' }`." Not "auth works." 4. **Pick the right level for each case** — see the "Test level guide" below. Default to the highest level where the test is still fast enough to run frequently. 5. **Call out what NOT to test.** This is as important as the list. Reasons: - Framew