test-planlisted

Before writing code (or before a PR ships), name the cases that must pass. A test plan is a filter that catches missed edge cases *before* the implementation locks in an assumption. ## 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. **Call out what NOT to test.** This is as important as the list. Reasons: - Framework behavior (Fastify parses JSON — no need to test that) - Trivial getters - Cases where the type system already guarantees the invariant - Third-party services (mock t