Write tests, run them, fix failures

Ask Claude Code to write tests for a file, run them and work through the failures in one go, without weakening a test just to make it pass.

Task: Write tests, run them, fix failures · Other tasks

Fill in the details

Code to test (required)

A file, module or function. In Claude Code you can type @ to reference a file.

Behavior and edge cases to cover

Optional. Cases you already know matter. Claude adds its own as well.

Test command

Optional. Leave empty and Claude will find how the project runs its tests.

If the code itself is wrong

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

Your prompt (you can edit it)

Write tests for [fill in: Code to test], run them, and fix any failures.

1. Read the code, its callers and the existing tests. Match their framework, file layout, naming and assertion style. Do not add a new test framework or dependency.
2. Cover the main behavior, edge cases such as empty, boundary and malformed input, and the error paths. Test through the public interface, not private details.
3. Run the tests. If you cannot tell how the project runs its tests, ask me instead of guessing.
4. For each failure, decide whether the test or the code is wrong. Fix mistakes in the tests yourself. If the code under test is wrong, describe the bug and wait for my decision before you change the code.
5. Never delete or skip a test, or loosen an assertion, only to make it pass.
6. Keep going until the new tests pass, then run the wider test suite once to confirm nothing else broke.

If the intended behavior is unclear from the code, list those cases and ask rather than writing a test that locks in a guess.

Finish with the final test output, a short list of the tests you added, and any bugs you found in the code.

1 required field is empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

A file or module has few or no tests and you want a working set of them in one request, run and passing, rather than a draft you still have to debug.
You are about to change the code and want tests in place first, so you can tell afterwards whether behavior changed.
The project already has a test setup that Claude Code can run from the terminal, so it can check its own work instead of stopping when the tests look finished.

When not to use it

The feature does not exist yet. Write the tests from the requirement first with the test-first template, so they describe what you want rather than what the code does.
You want coverage across many files driven by a coverage report. The coverage gaps template works from the actual numbers and picks the files for you.
The task is in a plain chat without file access. Paste the code and use the unit test template, because Claude cannot run tests there.

Why this structure

Writing, running and fixing are asked for together, so Claude keeps iterating on its own instead of handing back untested code and waiting for the next instruction.
Step 1 points Claude at the existing tests and callers. The new tests then use the same framework and style, and the callers show how the code is meant to be used.
Step 4 separates two kinds of failure. A mistake in a new test is Claude's to fix; a bug in the code under test is a finding, and the setting decides whether Claude fixes it or asks you first.
The rule in step 5 closes off the easy way out. Deleting a test or loosening an assertion turns a failure into a pass without making the code any better.
The final run of the wider suite in step 6 checks that a code fix did not break something elsewhere.
The note about unclear behavior asks Claude to list unclear cases instead of writing tests that freeze a guess. You decide what the code should do, and the tests record your answer.

Example input (fictional)

Code to test

app/parsers/feed.py

Behavior and edge cases to cover

Feeds with no items. Dates in both RFC 822 and ISO 8601 format. Items missing a link. A feed larger than 5 MB.

Test command

pytest tests/parsers

If the code itself is wrong

describe the bug and wait for my decision before you change the code

Follow-ups to send Claude

Which branches of the code are still not exercised by any test? Add tests for the ones that matter.
Run /init and make sure the test command you used is recorded in CLAUDE.md.
Show me the bugs you found as a list with the input that triggers each one, before you change any code.

Common mistakes

Accepting a passing run without reading the tests. Tests that only call the code and check nothing will pass and prove nothing.
Letting Claude fix the code under test without looking at the change. A new test can expose behavior that other code relies on, even if it looks wrong.
Naming a whole directory. A single file or module keeps the work reviewable; do larger areas one piece at a time.

Write unit tests: Get unit tests for a function or module in your framework, covering normal cases, edge cases and errors, with each test explained.
Write tests first, then implement: Have Claude Code write tests that describe a feature before any implementation, confirm they fail, then write code until they all pass.
Fill gaps from a coverage report: Point Claude Code at your coverage report and a target percentage; it adds tests to the lowest-covered files and shows the before and after numbers.

See all templates

Sources

Claude Code docs: Prompt library (Anthropic documentation)
Claude Code docs: Common workflows, work with tests (Anthropic documentation)
Claude Code best practices: Give Claude a way to verify its work (Anthropic documentation)