Unit Test Prompt (Edge Cases Included)
Write tests that catch bugs rather than inflate coverage: happy path, edge cases, error paths and a mock strategy.
You are a test-driven development specialist. Write unit tests that catch bugs, not tests that inflate coverage.
CODE
```[LANGUAGE]
[CODE]
```
CONTEXT
- Test framework: [FRAMEWORK]
- Purpose of the code: [PURPOSE]
- External dependencies: [DEPENDENCIES]
- Known risky behaviour: [RISK]
OUTPUT 1 — BEHAVIOUR INVENTORY
For each public function: what it does, what it accepts, what it returns or throws. Table form.
OUTPUT 2 — COVERAGE TABLE
Per behaviour: test or not, and why. Include what will not be tested (framework code, trivial getters).
OUTPUT 3 — TESTS
- Happy path: at least one test.
- Edge cases: empty input, null/undefined, boundary values, very large input, single-element list, unicode.
- Error cases: expected exception and message.
- Test names describe behaviour ("returns empty array when input is null"); "test1" is banned.
- Arrange / Act / Assert separated and commented.
- Mock only external dependencies; explain each mock in one line.
OUTPUT 4 — UNTESTABLE RISKS
Two behaviours that cannot be unit tested (time, randomness, filesystem, network) and the approach for each.
OUTPUT 5 — RUN
The command to run the tests and the expected output.
RULES
- Test the actual behaviour; do not test behaviour the code does not have. If the code has a bug, report it separately.
- No snapshot tests.
- Eight good tests beat forty meaningless ones.
- Match the project's code style: [STYLE].
A test that cannot fail is not a test, it is documentation.
02 — Variables
Fill in the brackets
The highlighted fields are the places where your own details go. You do not have to fill all of them; anything left empty is completed by the model's own assumption.
[LANGUAGE]
[CODE]
[FRAMEWORK]
[PURPOSE]
[DEPENDENCIES]
[RISK]
[STYLE]
03 — How to use
How to use it, step by step
- 01
Paste the unit under test, not the whole file; fewer dependencies means a clearer test.
- 02
Run the tests before reading them — a failing test is usually a wrong assumption in the test.
- 03
Do not delete the "not tested" rows; they prevent useless tests.
04 — Variations
Same prompt, different result
One prompt does not solve every case. These variations ask for the same job in a different tone, length or format — pick the one that fits.
pytest
Same tests in pytest: parametrize, fixtures, pytest.raises for error cases.
PHPUnit
Same tests in PHPUnit: data providers, setUp/tearDown, expectException.
05 — Tips
Notes that take the result up a level
- A test name that does not describe behaviour is useless six months later.
- Mocking your own code makes the test pass and production fail.
06 — FAQ
Frequently asked about Software and Code
Is 100% coverage necessary?
No. 80% with well-chosen tests is worth more than 100% of trivial assertions.
What if the model writes a wrong test?
Common. Run it; if it fails and the code is correct, the test's assumption is wrong.
Next
You may also find these useful
Code Writing Prompt: Clean, Testable Function
Defines a contract instead of a wish: language, version, input, output, error cases and tests.
Intermediate ChatGPTClaudeDebug Prompt: From "Why Doesn't It Work" to a Diagnosis
Converts "why doesn't it work" into a systematic diagnosis: reproduce, hypothesise, isolate, verify.
Intermediate ChatGPTClaudeRefactor Prompt: Improve Without Breaking Behaviour
Simplifies working code without changing behaviour, planned as reversible steps you can review one at a time.
Advanced ChatGPTClaudeSQL Query Prompt (Schema Included)
SQL written without the schema rarely runs; this prompt requires schema, relationships and expected output.
IntermediateThis page was prepared by the CopyPromt editorial team, first published 24 October 2026. Prompts are written to work across models; brand names are mentioned for identification only.