Claude Code System Prompts for Testing

Concrete Claude Code prompts to generate unit tests, find missing test coverage, write property-based tests, and diagnose flaky tests. Copy, fill, paste.

"Write tests for this" produces unit tests that pass by accident — they exercise the happy path, mock too aggressively, and miss every edge case. The prompts below force Claude into specific test categories with bounded scope.

Prompt 1 — Contract-first test generation

For function [FN_NAME] in [FILE], write tests using [FRAMEWORK].

Phase A — list the contract:
1. Inputs (types, valid range, what counts as invalid)
2. Outputs (return shape, side effects)
3. Failure modes (what raises/returns null)
4. Invariants (what's always true regardless of input)

Phase B — generate exactly 8 tests, named by behaviour:
- 2 happy-path tests with distinct inputs
- 2 boundary tests (smallest/largest valid input)
- 2 invalid-input tests (each raising the expected error)
- 1 idempotence/invariant test
- 1 regression test for [KNOWN BUG OR LIKELY-BUG SCENARIO]

Constraint: do NOT mock [FN_NAME] or anything it calls in the same module.
Mock only external IO (network, fs, clock, randomness).

Why it works: phase A makes Claude state the contract before writing tests, surfacing implicit assumptions. The 8-test budget forces selection — every test must earn its slot.

Prompt 2 — Coverage gap finder

Read [FILE] and its existing test file [TEST_FILE].
For each branch and edge case in [FILE]:
- Is there a test that exercises it? (yes/no/partial)
- If no: what's the minimal test that would?

Output as a table:
| Branch | Tested? | Suggested test (1 line) | Priority |

Priority scale:
- High: branch is reachable from user input
- Medium: branch is internal but logic-critical
- Low: defensive code unlikely to trigger

Prompt 3 — Property-based test scaffold

For [FN] in [FILE], write property-based tests using hypothesis (Python)
or fast-check (JS).

Step 1: Define the input strategies (types and constraints).
Step 2: List 3–5 properties that must hold for ANY valid input:
   - "output length is always <= input length"
   - "calling twice produces the same result" (idempotence)
   - "round-tripping returns the original"
   - "function never raises for inputs matching strategy"
Step 3: Write the test code.

Run the tests with default settings. If any property fails, do NOT
adjust the property — show me the failing input. We'll decide whether
the property or the code is wrong.

Prompt 4 — Flaky test diagnoser

Test [TEST_NAME] in [FILE] fails ~1 in 5 runs.
Without running it yet, list the top 5 likely causes:
- Timing (sleep, await without sync, retry-on-timeout)
- Shared state (module-level vars, global registries)
- IO leakage (filesystem, network, sockets not closed)
- Randomness (uncontrolled seeds, time.now)
- Test ordering (passes alone, fails with siblings)

For each cause:
- the exact code reading that would confirm or rule it out (file:line)
- a deterministic fix
- the cost of the fix (lines changed, perf impact)

Rank by likelihood.

Prompt 5 — Integration test scaffolder

Generate integration tests for [ENDPOINT] in [FILE].
Hit a real test database — do NOT mock the DB layer.

Scenarios to cover:
1. Successful create — verify DB row exists and matches input
2. Validation error — verify 400 response and no DB write
3. Auth failure — verify 401 and no DB write
4. Idempotent retry — same request twice produces one row, not two
5. Concurrent requests — two parallel creates with same ID either both succeed (if dedupe) or one fails cleanly

For each test: setup (fixtures), action (HTTP call), assertions (status + DB state + side effects).
Clean up the test DB row after each test in teardown.

Prompt 6 — The "tests that would have caught this bug" prompt

A production bug happened: [DESCRIBE BUG, 1 sentence].
The bad commit: [HASH or DIFF].
The fix: [FIX or DIFF].

Write the regression tests that would have caught this bug BEFORE the
bad commit shipped. Constraints:
- Each test must fail against the bad commit and pass against the fix
- Use the same framework as the existing test suite
- Place tests in [TEST_FILE_PATH]
- Add a comment with the incident date or ticket so future maintainers know why the test exists

Output: the test code, plus a 1-line explanation per test of why it would have caught the regression.

Anti-patterns that ruin generated tests

• Mocking the function under test — Claude will do this if not forbidden. The test passes; the function still breaks in prod.
• Asserting on the mock — expect(mockFn).toHaveBeenCalled() tests the test harness, not your code.
• Catch-all try/except in tests — swallows the real assertion. Forbid: "do not wrap assertions in try/except."
• One test per function, named test_foo — useless naming. Demand: tests named by behaviour, e.g. test_returns_empty_when_input_is_none.
• Snapshot tests without diff review — they pass by capturing whatever output Claude wrote first. Use sparingly.

Get every prompt in one place

The 6 testing prompts above are a subset of the testing chapter in the Claude Code Power Prompts pack (30 prompts total, 8 pages, six categories). Tonight's launch price: £3 for the first 10 buyers, then £5. Instant PDF via Stripe — paste into CLAUDE.md and Claude loads your house style every session.

Get the 30-prompt PDF →

Frequently asked questions

Free tools

More examples