Unit tests written from the spec
Tests derived from requirements rather than from the implementation, so they can fail. Written for Claude, free to copy, with every placeholder explained below.
The prompt
<role>
You write tests from specifications, not from implementations.
</role>
<specification>
{{specification}}
</specification>
<signature>
{{function_signature}}
</signature>
<task>
Write unit tests for the specification above using {{test_framework}}.
</task>
<constraints>
- Derive every test from the specification. Do not assume implementation details.
- Cover: the normal case, every stated edge case, empty and boundary input, and
every error condition the specification mentions.
- One assertion per test where practical, and a test name that states the expected behaviour.
- Where the specification is ambiguous, write the test you believe is correct and
add a comment marking the ambiguity rather than guessing silently.
- Do not write a test whose expected value you cannot derive from the specification.
</constraints>
<output_format>
Complete runnable test file. After it, list any ambiguities you found in the
specification.
</output_format>
Now write the tests.Open this in the prompt builder to adapt it, score it, and re-render it for a different model.
What to replace
| Placeholder | What to put there |
|---|---|
| {{specification}} | What the function must do — behaviour, not code. |
| {{function_signature}} | The interface being tested. |
| {{test_framework}} | e.g. Vitest, pytest, JUnit. |
Why this prompt works
- Spec-derived, not code-derived
- Tests written from an implementation assert what it does, bugs included. Deriving from the spec is what allows a test to fail.
- Ambiguities surfaced, not resolved
- A vague spec produces a silently-wrong test. Flagging ambiguity turns a hidden assumption into a decision you get to make.
- Behaviour-stating test names
- Makes a failing test readable in CI without opening the file.
More prompts
- Code review for correctness only — Findings with a triggering input, ranked by severity — and permission to find nothing.
- Debug from an error and stack trace — Ranked hypotheses with a test for each, instead of one confident guess.
- Explain unfamiliar code — A walkthrough pitched at your actual level, with the non-obvious decisions called out.
- SQL query from a plain-English question — A query with its assumptions stated, so you can check them before running it.
- Blog post from an outline — Turn a rough outline into a full draft that keeps your structure and does not pad.
- Rewrite for clarity without changing meaning — Tighten prose while keeping the author's voice and every factual claim intact.
Browse the full prompt library, all coding & development prompts, or read the guides.