Prompt to write unit tests

Paste this into a chat window and replace each {{variable}}, or open it in the prompt builder to fill them in a form. Sections are marked with XML tags, which every major model reads well.

You are a careful {{language}} engineer who writes tests that catch real regressions and survive refactoring.

<context>
The code under test:
<code>
{{code}}
</code>

An existing test in this project, to match its style and helpers:
<style_example>
{{existing_test}}
</style_example>
</context>

<constraints>
- Test behaviour through the public interface, not private helpers or the order of internal calls.
- Cover: the normal case, boundaries (empty, zero, one, maximum), invalid input and each error the code can raise or return.
- Mock only what crosses a process boundary, such as the network, the clock or the file system. Use real objects otherwise.
- Give each test a name that states the expected behaviour.
- If the code has a bug that a test exposes, keep the test, mark it clearly, and explain the bug after the code. Never weaken a test to make it pass.
</constraints>

<output_format>
One code block with the complete test file, ready to run. After it, a short list of any behaviour you couldn’t test without changing the code, and why.
</output_format>

<task>
Write unit tests for the code above using {{framework}}. Cover the behaviour a caller relies on, including edge cases and failure paths.
</task>

You are a careful {{language}} engineer who writes tests that catch real regressions and survive refactoring.

<constraints>
- Test behaviour through the public interface, not private helpers or the order of internal calls.
- Cover: the normal case, boundaries (empty, zero, one, maximum), invalid input and each error the code can raise or return.
- Mock only what crosses a process boundary, such as the network, the clock or the file system. Use real objects otherwise.
- Give each test a name that states the expected behaviour.
- If the code has a bug that a test exposes, keep the test, mark it clearly, and explain the bug after the code. Never weaken a test to make it pass.
</constraints>

<output_format>
One code block with the complete test file, ready to run. After it, a short list of any behaviour you couldn’t test without changing the code, and why.
</output_format>

<context>
The code under test:
<code>
{{code}}
</code>

An existing test in this project, to match its style and helpers:
<style_example>
{{existing_test}}
</style_example>
</context>

<task>
Write unit tests for the code above using {{framework}}. Cover the behaviour a caller relies on, including edge cases and failure paths.
</task>

{{language}}

The language, such as Python or TypeScript.

{{code}}

The function or module to test, including the types it uses.

{{existing_test}}

One existing test file or test from the project, so the output uses the same imports, fixtures and naming. Write “none” for a new project.

{{framework}}

The test framework and any helpers, such as pytest with hypothesis, or Vitest with Testing Library.

{{language}}

Python

{{code}}

def parse_duration(text: str) -> int:
    """Parse "1h30m", "45s" or "2h" into seconds."""
    units = {"h": 3600, "m": 60, "s": 1}
    total, number = 0, ""
    for ch in text.strip():
        if ch.isdigit():
            number += ch
        elif ch in units and number:
            total += int(number) * units[ch]
            number = ""
        else:
            raise ValueError(f"bad duration: {text!r}")
    return total

{{existing_test}}

def test_slugify_lowercases_and_joins_words():
    assert slugify("Hello World") == "hello-world"

{{framework}}

pytest, with pytest.mark.parametrize for tables of cases

What to look for. A good test file includes a case for trailing digits with no unit, such as "90". The function returns 0 there instead of raising, which is a real bug that the “keep the test and explain it” rule should surface rather than hide.

You are a careful Python engineer who writes tests that catch real regressions and survive refactoring.

<context>
The code under test:
<code>
def parse_duration(text: str) -> int:
    """Parse "1h30m", "45s" or "2h" into seconds."""
    units = {"h": 3600, "m": 60, "s": 1}
    total, number = 0, ""
    for ch in text.strip():
        if ch.isdigit():
            number += ch
        elif ch in units and number:
            total += int(number) * units[ch]
            number = ""
        else:
            raise ValueError(f"bad duration: {text!r}")
    return total
</code>

An existing test in this project, to match its style and helpers:
<style_example>
def test_slugify_lowercases_and_joins_words():
    assert slugify("Hello World") == "hello-world"
</style_example>
</context>

<constraints>
- Test behaviour through the public interface, not private helpers or the order of internal calls.
- Cover: the normal case, boundaries (empty, zero, one, maximum), invalid input and each error the code can raise or return.
- Mock only what crosses a process boundary, such as the network, the clock or the file system. Use real objects otherwise.
- Give each test a name that states the expected behaviour.
- If the code has a bug that a test exposes, keep the test, mark it clearly, and explain the bug after the code. Never weaken a test to make it pass.
</constraints>

<output_format>
One code block with the complete test file, ready to run. After it, a short list of any behaviour you couldn’t test without changing the code, and why.
</output_format>

<task>
Write unit tests for the code above using pytest, with pytest.mark.parametrize for tables of cases. Cover the behaviour a caller relies on, including edge cases and failure paths.
</task>

• Claude

  In an agent loop, Anthropic suggests telling Claude not to hard-code values or special-case test inputs, and to say if a test is wrong rather than working around it. Add that line if the model will also edit the code under test.

• OpenAI GPT

  If the first output misses the style, add the existing test as a worked example rather than more rules. OpenAI suggests reasoning models try zero-shot first and add examples only when the output misses.

• All models

  Run the tests. The model can’t execute code in a plain chat, so a test that looks right may fail on an import or a fixture name; an agent with a terminal can run and fix them in one pass.

• Generate test dataRealistic fixtures that match your schema, with deliberate edge cases and clearly fake personal data.
• Code reviewReview a diff for bugs, risky changes and missing tests, ranked by severity with line references.
• Refactor codeRestructure code toward one stated goal without changing behaviour, with risky steps flagged.

Building this into an app that sends the same instructions with every request? Start from a system prompt instead; each comes with design notes, failure modes and a monthly cost. In the system prompt library: Unit test writer.

Edited the template? Compare your version with this one in the prompt diff, and count it for your model with the token counter. Browse all 29 prompt templates.