# 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.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
Write tests for {{path}}, run them, and fix any failures.
{{#focus}}

Make sure the tests cover:
{{focus}}
{{/focus}}

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{{#command}} with: {{command}}{{/command}}. 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, {{bugs}}.
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.
```

## Fields

- `{{path}}` (required): Code to test. A file, module or function. In Claude Code you can type @ to reference a file.
- `{{focus}}`: Behavior and edge cases to cover. Optional. Cases you already know matter. Claude adds its own as well.
- `{{command}}`: Test command. Optional. Leave empty and Claude will find how the project runs its tests.
- `{{bugs}}`: If the code itself is wrong. Choose one:
  - describe the bug and wait for my decision before you change the code (default)
  - fix it with the smallest change and list each fix in your summary

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

## 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.

## Related templates

- [Write unit tests](https://awesomeclaudeprompts.com/prompts/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](https://awesomeclaudeprompts.com/prompts/test-first-feature/): 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](https://awesomeclaudeprompts.com/prompts/fill-coverage-gaps/): 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.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code docs: Common workflows, work with tests](https://code.claude.com/docs/en/common-workflows#work-with-tests) (Anthropic documentation)
- [Claude Code best practices: Give Claude a way to verify its work](https://code.claude.com/docs/en/best-practices#give-claude-a-way-to-verify-its-work) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.