# 3 · Automate: tests that catch real breakage An automated test is a promise that keeps being checked after you've gone. It's only worth something if it fails when the thing a person relies on breaks, and only then. A test that can't fail gives false comfort; a test that fails at random teaches the team to ignore red. Code craft `4-verify.md` covers the basics for your own change: test behaviour, not mocks of the thing under test (V2), and never weaken a test to make it pass (V3). This file is about the suite as a whole: what to test, at what level, and how to keep it trustworthy. --- > **In ihumane Pro** (https://ihumane.ai/#pricing): > - A1 · Write the tests from the plan, not from the code > - A2 · A fake must behave like the real thing > - A3 · Test at the level where it can break > - A4 · A flaky test is a bug: find the cause > - A5 · Find things the way a person does, and wait for what they wait for > - A6 · Coverage counts lines run, not things checked ## Summary checklist - [ ] Every "working" line and risk has a test named for the behaviour, or is listed as tested by hand. - [ ] Every fake is built from a real response, and at least one failure is faked. - [ ] Each risk is tested at the level where it would break; at least one test goes through the real join. - [ ] No retries, raised timeouts or reruns used to get a pass; flaky tests found and fixed or reported. - [ ] End-to-end tests find elements by role, label or text, and wait for results, not seconds. - [ ] No coverage number offered as proof. - [ ] `checks/trust.js` and Code craft's `checks/tidy.js` run on the test files you touched.