Tests as the agent's compass (TDD with agents)

An agent without a check is guessing, and it will tell you the guess worked. An agent with a failing test has a direction, a finish line and a way to notice its own mistakes.

That’s why I treat tests as the most important input to any agent run. More important than the prompt.

Why a red test beats a good prompt

A prompt describes what you want in words, and words are ambiguous. A failing test describes it as an exit code. The agent can run it, read the failure, change something and run it again, as many times as it needs, without you in the loop.

1. 🔴RedA test that fails for the right reason
2. ↓→
3. 🔒LockYou review and commit the test
4. ↓→
5. 🛠️Agent iteratesEdit, run, read failure, repeat
6. ↓→
7. 🟢GreenTest passes, test file untouched
8. ↓→
9. 🧹RefactorClean up with the suite as a net

↺ One behaviour per loop

Who writes the test?

You don’t have to write every test yourself. But you do have to own them. If the agent writes the test and the code in one go, a misunderstanding gets encoded twice, and the test happily confirms the bug.

The brief I use

Two short runs. The first produces tests only; the second makes them pass.

Run 1 — tests only
Write failing tests for: cancelling an order refunds the full amount
when it's cancelled within 24 hours, and 50% after that.
Put them next to the existing order tests and follow their style.
Do not write or change any implementation code.
Stop when the tests run and fail because the behaviour is missing.

Run 2 — implementation
Make the tests in orders/cancel.test pass.
Do not modify, skip or delete any test. If you believe a test is
wrong, stop and explain why instead of changing it.
Done when: the full test suite passes.

For refactors, flip it: ask the agent first for characterization tests that pin down current behaviour, commit those, then refactor against them. We’ll see in lesson 4.4 what happens when a test is left unlocked.

Check yourself

🧠 Tests and agents

Score: 0 / 4

1. 1. Why should you commit the failing tests before the agent implements anything?

   It makes the git history prettierSo any change to them shows up plainly in the diffAgents can't read uncommitted filesIt speeds up the test runner

   Once committed, a modified or deleted test is one command away from being spotted. That's your tripwire against a gamed check.

2. 2. Your new test fails with 'module not found'. What do you do?

   Hand it to the agent, it'll figure it outFix the test until it fails because the behaviour is missingDelete it and write the code firstMark it as skipped

   Red has to mean 'the feature doesn't exist yet'. Otherwise the agent may 'fix' the test setup and call it done.

3. 3. What's the main risk of 'implement this and add tests' in one prompt?

   The agent writes too many testsThe tests end up confirming whatever the code does, bugs includedTests will be slowerThere's no risk

   Tests written after, by the same run, tend to mirror the implementation. They pass, and prove little.

4. 4. You're about to have an agent refactor a module with no tests. First step?

   Refactor carefully and review line by lineAsk for characterization tests of current behaviour and commit themAdd types onlySkip tests, refactors don't change behaviour

   Pin today's behaviour first. Then 'no behaviour change' becomes something the agent can actually check.

↺ Try again

Before you move on

✅ Key takeaways

0 / 5 completed

• I give agents a failing test, not just a description, whenever the behaviour is checkable.
• I read and own every test before it becomes the agent's target.
• I commit tests before implementation so changes to them are obvious.
• My implementation briefs say: don't modify tests, stop and explain instead.
• Before an agent refactor, I pin current behaviour with characterization tests.

↺ Reset