Tests that matter

Professional codebases carry thousands of automated tests; your v1 needs a strategy sized to a solo shipper — one that catches real regressions without turning the course into a testing course. Two layers, honestly chosen:

• The manual test script — your app's preflight checklist. A TESTING.md file: 12-15 numbered steps covering the loop end to end (paste in a message → appears in inbox → open → draft with AI → edit → send → status flips → refresh → everything holds → filters work → empty states show → the by-hand path works with drafting disabled). Run it before every deploy and after every risky change. Unautomated but written beats automated-someday: the discipline is the checklist existing and being run, and pilots have shipped humans on exactly this technology for a century.
• Automated door tests for the API — the highest-value automation per minute invested: a handful of tests that knock on each route with good and bad payloads and assert the answers (list returns seeded rows; bad status gets 400; orphan reply gets refused; the AI route rejects a missing message_id). The assistant writes these with a standard test runner in twenty minutes; npm test runs them in seconds forever after. Doors are worth automating because they're stable contracts — screens change weekly, contracts shouldn't.
• **What you're not testing yet, on purpose**: component rendering details (churning too fast at your stage), the model's draft quality (that's eval territory — the customer-agents and LLMOps courses when you're ready), and cross-browser pixel perfection. Write these in TESTING.md under 'consciously deferred' — a documented punt is a decision; an undocumented one is a gap.

Regression thinking (the habit behind both layers)

The bug that hurts isn't the one in the feature you're building — you're staring at that one. It's the one your change caused three screens away. Hence the rule every course in this academy converges on from a different direction: after any change touching shared code (the db module, a route, a heavily-reused component), run the full script and the door tests, not just the feature you touched. When a bug does slip through, it earns a permanent seat: add the step that would have caught it to the script, or the case to the door tests. Your test suite should be a museum of every bug that ever fooled you — that's what makes it yours, and it's the same suite-grows-from-failures discipline that runs this company's eval pipelines.