Prompt · Code
Test case generation prompt
Filling the gaps in a test suite, where the value is entirely in the cases the author did not think of.
Write tests for the function below.
<code language="{{language}}">
{{code}}
</code>
Use {{framework}}.
Prioritise in this order:
1. Boundary values — zero, one, empty, maximum, one past maximum, negative where the type allows it.
2. Invalid and hostile input — null, wrong type, malformed, unexpectedly large.
3. Error paths — every branch that raises, returns an error or fails, including the cleanup that should happen.
4. The happy path — one test, not five.
For each test:
- Name it after the behaviour it verifies, not after the function.
- Assert one behaviour.
- Include the reason it exists as a short comment when the case is not obvious.
Skip anything that only re-tests the language or the framework. If the code has a branch you cannot reach from the public interface, say so instead of writing a test for it — that is a design finding, not a missing test.What to fill in
{{language}}- Determines idioms and assertion style.
{{code}}- The function plus its type signatures. Include the types it depends on.
{{framework}}- pytest, Jest, Go testing, JUnit. Naming and structure differ enough to matter.
Why it is written this way
Every rule in the prompt is there because of a specific failure it prevents. Knowing which is which is what lets you adapt it instead of only pasting it.
The happy path is capped at one
Left to itself, a model writes five variations of the case that already works, because those are the easiest tests to write. Capping it forces the effort into the cases that find bugs.
Boundaries come first
Ordering is instruction. The first category listed gets the most attention, and boundary conditions are where most real defects live.
Unreachable branches are reported, not tested
A test that reaches into private state to hit a branch is a test that will break on the next refactor. Surfacing it as a design finding is more useful than papering over it.
One assertion per test
A test with six assertions reports the first failure and hides the rest, which turns one debugging session into six.
The version most people write, and what it costs
Write unit tests for this function:
{{code}}You get four tests of the happy path with different variable names, a test that asserts the language works, and no coverage of empty input, the error branch, or the boundary at zero — which is where the actual bug is. Coverage goes up and nothing is caught.
What it still gets wrong
- It tests the code as written, including its bugs. A function that returns the wrong value consistently gets a test asserting the wrong value.
- It cannot know your business rules. "Should this reject a negative amount?" is a question only your domain answers.
- Generated tests need reading before committing. An unread test is a future false confidence.
Check it before you ship it
- Evaluation Dataset BuilderCases with expected outputs and difficulty, exported three ways.
- AI Skill GeneratorThree skill shapes — review, generate, diagnose — each producing a complete file.
- LLM Token CounterReal BPE tokenization, not characters ÷ 4. Shows which counts are exact and which are estimates.
To build one of these from scratch for a task not covered here, the prompt generator assembles the same structure — delimiters, output contract, edge cases — from an expert-authored blueprint, and the prompt review checklist is what to run over the result.