You know tests are your safety net, and that the critical paths come first. But there is more than one kind of test. One checks a single tiny piece on its own; another checks that two pieces still work where they meet. Which kind you reach for decides where you catch the bug, and how fast. This chapter gets you that difference, so you can tell the agent exactly what to protect.
8.2.1A unit test checks one piece
A unit test checks one small piece of your code, usually a single function, on its own. You hand it an input, it runs that one piece, and it checks the output matches what you expected. Nothing else runs, no database, no whole app, just the piece.
That isolation is the point. When it fails, it fails fast and names the exact function, not a vague "something broke somewhere."
A tool like Vitest runs hundreds of these in a second. It is the fast default on a modern JavaScript build; Jest does the same job and you will meet it in older projects. Every language ships its own: pytest for Python, go test built into Go, JUnit for Java, RSpec for Ruby. Name yours and the rest of this part is identical.
8.2.2An integration test checks the seams
An integration test checks that two pieces still work where they meet. The bug is rarely inside one clean function; it hides at the seam, where your code hands off to the database, or where two modules trusted different assumptions.
So you exercise the real seam. Save a record, load it back, and check you got the same thing out, with the actual database running underneath:
If saving and loading ever stop agreeing, this turns red. A unit test on either one alone would sail straight past it.
8.2.3Test the logic that matters
You do not test every line, and you do not test a function that just hands back a value. You test the logic that would hurt if it were wrong: the pricing math, the discount rule, the check that decides who gets in.
Rule of thumb: if a mistake there would cost money, lose data, or let the wrong person in, it earns a test. If it is ordinary, skip it.
8.2.4Let the agent write them
You hand-write none of this. You name the behavior to protect; the agent writes the tests and runs them. The judgment is yours: which logic is worth the net, which seam is fragile. Give it that and it fills in the cases you would forget, the zero, the empty input, the one that should throw an error.
This prompt hands your agent the logic to protect:
Do this now: paste the prompt, name the one piece of logic that would hurt most if it broke, and let your agent write the tests that pin it down.
