Writing Tests: What to Test and How to Test It

Series: Claude Learning Journey · Intermediate Usage

Tests are documentation that never goes stale. A good test suite tells you what the code is supposed to do, what the edge cases are, and what breaks when someone changes the wrong thing. Claude can write tests fast, but it cannot yet know what your code is for — that context has to come from you.

The value of Claude in testing is not replacing the thinking about what to test. It is replacing the mechanical work of writing the test once you know what you want. This is a meaningful split because the thinking is the hard part.

What to Test: The Useful Heuristic

The question “should I test this?” is answered by: what happens if this breaks? If the answer is “nothing much,” skip the test. If the answer is “customers cannot pay,” write the test.

Useful categories of tests:

• Happy path for core functionality
• Edge cases that have actually caused bugs
• Error conditions that should be handled
• Integration points with external systems

The tests Claude writes well are the ones where you specify the inputs, expected outputs, and what the code is supposed to do. “Test that the payment function returns an error when the card is declined” is a good prompt. “Add some tests” is not.

Writing Test Cases from Bug Reports

One of the most useful testing patterns with Claude: take a bug report and ask it to write the test that would have caught the bug. This works because a bug report usually contains a specific scenario, an observed behaviour, and an expected behaviour. That is most of what a test needs.

You: "Here's a bug report: when a user submits a form with an apostrophe in their name, the database insert fails with a syntax error. Expected: the apostrophe should be escaped. Write a test that reproduces this scenario."

Claude writes the failing test. You verify it fails for the right reason. Then you fix the code and verify the test passes.

Mocking and External Dependencies

Claude is good at writing tests for isolated units of code. It is less good at knowing how to mock external dependencies. Give it the mock structure you want — how your project handles database mocks, HTTP client mocks, time mocks — and it will write tests that fit your patterns.

Without that context, it will guess, and the mocks will be wrong.

What You’ll Learn

• The useful heuristic for deciding what to test
• Writing tests from bug reports
• How to give Claude the context it needs for good mocks
• The limits of test generation

Try It Yourself

Take a recent bug from your issue tracker. Write a test that reproduces the bug before you fix the code. Give Claude the scenario, the expected behaviour, and the relevant code. Use the test to verify the fix when you are done. Notice how the discipline of writing the test first clarifies what you actually expect to happen.

What’s Next

With testing covered, stage 3 is complete. Stage 4 is where Claude use gets interesting: we move from using Claude as a helpful tool to using it as an autonomous agent that can handle multi-step tasks on your behalf.

Part of the Claude Learning Journey series · Next: Autonomous Tasks: Delegating Real Work to Claude