Coding

Testing

Get Claude to write tests that actually protect you, not tests that just pass.

Knowledge cards
Knowledge card
Mine Claude for the Edge Cases You Missed
A testing pattern where, rather than asking Claude to write tests, you first ask it to enumerate the edge cases and failure modes of a function — then decide which deserve tests. It's using Claude as an adversary against your code, not a scribe.
L2 · Context engineering
Best practice
Make Claude Test Behaviour, Not Implementation
A prompting discipline that tells Claude to assert what a unit does from the outside — given these inputs, expect these outputs or effects — rather than how it does it internally. The test describes a contract, not a call sequence.
L3 · Workflows
Knowledge card
Turn Your Examples Into Table-Driven Tests
A testing pattern where you give Claude a set of concrete input-to-output examples and ask it to generate a single table-driven (parameterized) test that runs each example as a row, rather than a separate test function per case.
L2 · Context engineering
Best practice
Ask for the Test That Would Have Caught the Bug
A rule for bug fixes: before Claude changes any code, have it write the single test that fails today because of the bug and will pass once the bug is gone. The test, not the patch, is the deliverable you review first.
L2 · Context engineering
Claude for testing

Test the behaviour, not the implementation

Ask Claude for tests and you can get two very different things: tests that pin down what the code should do, or tests that merely restate what it currently does. The first protects you; the second passes while the behaviour is wrong. Steer Claude toward the first by naming the behaviour you care about — 'a user with an expired token is rejected', not 'call the function and assert it returns'. Tests written against behaviour survive refactors and catch real regressions; tests bolted to the implementation break on every change and prove nothing.

Write the test that would have caught the bug

When you fix a bug, have Claude write the test that would have failed before the fix and passes after. That single test turns a one-off fix into a permanent guard against the bug returning in a new shape. Give Claude the reproduction and ask for the minimal test that captures it. Over time these accumulate into a suite that documents your real failure modes — far more valuable than a pile of tests that only confirm the happy path.

Frequently asked
How do I get useful tests from Claude?

Name the behaviour you want protected rather than asking it to test the implementation. Behaviour-focused tests survive refactors and catch real regressions; implementation-bound ones break on every change.

What test should I write after fixing a bug?

The one that would have failed before the fix and passes after. Give Claude the reproduction and ask for the minimal test capturing it, so the bug cannot return unnoticed.

Why do Claude's tests sometimes prove nothing?

Because they restate what the code currently does rather than what it should do, so they pass even when behaviour is wrong. Anchoring tests to intended behaviour fixes this.