Skip to content
Shelf

Coding

Write unit tests that cover the edge cases

Generates a test suite for a function or class, including the boundaries and failure paths people forget, and lists any bugs it noticed along the way.

By Hannah LindgrenVersion 1Updated 7 Oct 2026

Prompt

Markdown
Write unit tests for the code below.

Language and test framework: {{framework}}

Before writing any tests, list the behaviors worth testing, grouped as:
- Normal cases: typical valid input.
- Boundaries: empty, one item, the maximum, zero, negative numbers, the first and last positions.
- Invalid input: wrong type, missing fields, malformed data.
- Failure paths: every error the code can raise or return, and what triggers it.

Then write the tests.
- One behavior per test. Name each test after the behavior it checks, so a failure explains itself.
- Arrange, act, assert, with a blank line between each part.
- Check results, not implementation details. Do not test private helpers directly.
- Mock only what crosses a boundary: network, database, clock, file system, randomness.
- Each test must be able to run alone and in any order.

Rules:
- Match the conventions of the framework I named.
- If the code has behavior that looks like a bug, do not write a test that locks it in. List it under "Possible bugs" and say what you think the correct behavior is.
- If something cannot be tested without changing the code, say what change would make it testable.

Code:
{{code}}

Use this prompt

Result

Write unit tests for the code below.

Language and test framework: {{framework}}

Before writing any tests, list the behaviors worth testing, grouped as:
- Normal cases: typical valid input.
- Boundaries: empty, one item, the maximum, zero, negative numbers, the first and last positions.
- Invalid input: wrong type, missing fields, malformed data.
- Failure paths: every error the code can raise or return, and what triggers it.

Then write the tests.
- One behavior per test. Name each test after the behavior it checks, so a failure explains itself.
- Arrange, act, assert, with a blank line between each part.
- Check results, not implementation details. Do not test private helpers directly.
- Mock only what crosses a boundary: network, database, clock, file system, randomness.
- Each test must be able to run alone and in any order.

Rules:
- Match the conventions of the framework I named.
- If the code has behavior that looks like a bug, do not write a test that locks it in. List it under "Possible bugs" and say what you think the correct behavior is.
- If something cannot be tested without changing the code, say what change would make it testable.

Code:
{{code}}

Still to fill in: framework, code

Test run

Fill in framework, code to run it. A blank input would spend a test run on a prompt with holes in it.