Verify with Tests
"Done! The feature works" is a claim. A test run that passes is evidence. Much of this course comes down to one habit: never accept the claim without the evidence.
The rule
Done means a check passed, not that Claude said so.
Tests turn a fuzzy request into a target the agentic loop can hit. A few habits make them work well with an agent:
- Test first. Ask for a test that captures the requirement, and watch it fail before any feature code exists. A failing test proves it can tell "missing" from "present".
- Fail for the right reason. The failure should say the behaviour is missing ("expected 6 deliveries, got 7"), not that the test itself is broken by a typo or a bad import.
- Say how to run the checks. Put the command, such as
pytest -q, inCLAUDE.md, so Claude runs it on its own in every session. - Forbid the shortcut. "Don't change or skip the tests" closes the easiest way to fake a pass.
- Run it yourself.
! pytest -qat the end is your independent confirmation. - Go beyond unit tests when it matters: a linter, a type checker, or opening the app and trying the feature the way a customer would.
Write a test: pausing tomorrow removes exactly one delivery.
Run it and show me it fails. Don't write the feature yet.Now implement it in orders.py. Don't change or skip the test.
Run pytest -q until everything passes.Sending these as two separate messages matters. Ask for the test and the feature together and you never see the red step, so you cannot tell a test that detects the missing behaviour from one that would have passed anyway.
The shortcut
Red, green, look. Red: see the test fail for the right reason. Green: make it pass without touching the test. Look: read the diff and run the checks yourself.
Plan
In plan mode you agree on the rule: customers can pause tomorrow's delivery until 8 p.m. tonight.
The trap hides at both ends. A test that fails for the wrong reason proves nothing, and a test that passes because it was edited proves even less.
Drills
Answer fast — trust the rule.
Claude says "All done, the feature works" but ran nothing. What do you do?
Why watch a new test fail before writing the feature?
The new test fails with NameError: name 'weekly_ordr' is not defined. Is that a good "red"?
Where should the command for running the tests be written so Claude uses it every session?
Remember
- Done means a check passed, not that Claude said so.
- Shortcut: red, green, look.
- Trap: a test that fails for the wrong reason, or passes because it was changed.