Claude Code Prompt for Testing: 12 Test Prompts to Copy

A Claude Code prompt for testing should make Claude prove its work by running your tests, not just writing them. The 12 prompts below follow the loop Anthropic recommends in its Claude Code best practices: plan first, write a failing test that reproduces the issue, fix the code, then run the suite. Paste them into Claude Code inside your repo and fill in the brackets.

Set up Claude Code for testing

Anthropic's guidance is to give Claude a way to check its own work, and tests are the clearest check. Put your test commands in CLAUDE.md (run /init to create a starter file) so every session knows them. Use plan mode, toggled with Shift+Tab or started with claude --permission-mode plan, when you want Claude to read and propose before it edits. If you want a hard rule, a Stop hook in .claude/settings.json can run your tests and keep Claude working until they pass.

Plan the tests

1. Test plan from code

In plan mode: read @[file] and its existing tests. List every behavior the code should guarantee as a test name, plus edge cases (boundaries, empty input, nulls, time zones). Say which test file you would extend. Do not edit anything yet.

2. Coverage gap scan

Run [coverage command] and list the functions in [folder] with untested branches. Rank them by risk to users, not by line count, and propose the first five tests to add.

3. Behavior rules to tests

Here are the rules this feature must follow: [rules]. Turn each rule into one or more test names for [framework] and point out any rule that is ambiguous before writing code.

Write tests first

4. Reproduce the bug

Bug report: [report]. Write a failing test in [test file] that reproduces it. Run [single file command] and paste the failure. Confirm it fails for the reported reason, not an import or typo. Do not fix the code yet.

5. Boundary set

For the rule "[rule with a threshold]" in @[file], write tests for just under, exactly at, and just over the line, plus zero and the largest allowed value. Run them and report which fail.

6. Writer and checker split

Write only tests for [feature] from this spec: [spec]. Do not look at or change the implementation. When done, list the tests and the behavior each covers so a separate session can write code to pass them.

Fix and prove

7. Fix without weakening tests

Make the failing tests in [test file] pass by changing only [target files]. Do not edit, skip, or loosen any assertion and do not touch [protected paths]. Run [single file command], then [full suite command], and paste both summaries.

8. Flaky test hunt

The test [name] fails sometimes. Run it [number] times with [command], collect the failures, and find the cause (timing, shared state, order, network, dates). Propose a fix to the test setup or code, not a retry wrapper.

9. Real objects over mocks

Review the tests in [test file] for mocks that hide real behavior. For each mock, say whether a real object, an in-memory fake, or a test database would be safer here, and rewrite one test to show the change.

Automate and review

10. Test rules for CLAUDE.md

Based on this repo's test setup, draft five short lines for CLAUDE.md: the test commands, where tests live, naming style, the mocking policy, and one rule about [common bug type]. Keep each line under 20 words.

11. Headless test check for CI

Write a shell step for CI that runs claude -p with --output-format json to review the tests changed in this branch against the code changed, and fails the step if any new code path has no test. Show the command and how to read the result.

12. Test review before PR

Review the tests in this branch's diff. For each, say whether it would fail if the feature broke, whether it tests behavior or internals, and which edge case is still missing. Rank fixes by risk.

Worked example

A TypeScript shop had a bug: carts of exactly $50.00 were charged $5.99 shipping when the rule says $50.00 or more ships free. The developer filled the flagship prompt with @src/cart/shipping.ts, the rule, the vitest commands, and "no mocks needed". In plan mode, Claude Code spotted the cause (a "greater than" check where "greater than or equal" was needed) and proposed four boundary tests: 4999, 5000, 5001, and 0 cents.

After approval it wrote the tests, ran them, and showed exactly one failure, at 5000 cents, matching the bug report. It changed one condition, reran the file and the full suite, and reported a before and after table plus an untested case (negative amounts) for the developer to decide. Copy the full Claude Code testing prompt.

Related coding prompts

For a tool-agnostic starting point, see the automated unit test generator. Before you open a pull request, use the Claude Code prompts for code review. For safe refactors, the tests-first refactoring prompt keeps changes small, the Claude Code hooks config writer sets up a Stop hook that runs your tests, and Python teams can use the pytest fixture design prompt.

Find more in the Agents prompts hub, browse all prompts, or share your own prompt.