Software and Code Intermediate 2 min read

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.

Works with: ChatGPTClaudeGeminiCopilot Updated: 24 October 2026
Prompt 1410 characters · 7 variables
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

  1. 01

    Paste the unit under test, not the whole file; fewer dependencies means a clearer test.

  2. 02

    Run the tests before reading them — a failing test is usually a wrong assumption in the test.

  3. 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

This 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.