You have seen tests as a safety net you add after the code already works. There is a sharper move that flips the order: you write the test first, before the code exists, describing exactly what success looks like. Then the agent writes code until that test passes. This chapter shows you how to run that loop with an agent, and when the flip is worth it.
8.6.1Write the test before the code
Test-driven development (TDD) means writing the test before the thing it tests. You describe the behavior you want as a test that must pass, then write only enough code to make it pass. The test is not a check you bolt on at the end. It is the specification you build toward.
The order sounds backwards until you see what it buys. You cannot write a test for "checkout works" without first deciding what "works" means. Writing the test first forces that definition before a single line of the feature exists.
8.6.2Red, green, refactor
The cycle has a name, red-green-refactor, and three beats you repeat:
- Red: write one small failing test and run it. It fails because the code it needs does not exist yet, and that red proves the test really checks something.
- Green: write the least code that makes the test pass. Nothing extra, nothing clever, just green.
- Refactor: with the test passing, clean up the code, improving its shape without changing what it does. It stays green, so you know the cleanup broke nothing.
8.6.3Why it fits AI so well
Handing an agent a failing test is the most precise instruction you can give it. Most prompts describe what you want in words the agent can read loosely. A test is exact: this input must produce that output, and the machine runs it to check.
It also closes the agent's favorite escape hatch. An agent will cheerfully report a feature done. A red test that has to go green is a fact it cannot talk its way around, so you get a spec it codes toward and a finish line it cannot fake.
8.6.4When to use it, when to skip it
TDD shines when you can state success exactly before you build. It gets in the way when you are still discovering what you want.
| Write the test first | Skip it, cover it after |
|---|---|
| Tricky logic with a right answer (pricing, dates, permissions) | Exploratory UI you are still shaping |
| A bug: write the test that reproduces it, then fix to green | A quick prototype you may throw away |
| A rule you must never break again | A layout you judge by eye, not by assertion |
The dividing line is that one question: can you write down what "correct" means before the code exists? When you can, write the test first. When the honest answer is "I will know it when I see it," build first and cover it after, the way the safety-net chapter showed.
8.6.5Turn every bug you fix into a test
This is the habit worth more than any other in this part, and it is free: every bug you fix gets a test before it is closed. You already have the ingredient, the repro you wrote when you proved the fix was real.
Turn that repro into a test and run it against the code from before the fix. It must fail. Then apply the fix and watch it pass.
That is the red-then-green cycle, handed to you by the bug itself. It is also the only thing that stops your agent quietly reintroducing the same bug three weeks from now.
Do this now: pick one piece of tricky logic in your app, write the failing test for it first, and let your agent turn it green before it writes anything else.
