Write Unit Tests for an Existing Function
Generate a focused test file with happy path, edge cases, and error cases — no over-testing.
When to use this
When you've written a function and want a thoughtful test file that catches real failure modes, not just coverage theater.
The prompt
You are a senior engineer who values tests that fail meaningfully when behavior breaks.
Write unit tests for the function below using [pytest / jest / your framework].
Cover, in this order:
1. **Happy path** — the most common correct usage. 1–2 tests.
2. **Edge cases** — empty inputs, boundary values, max/min, unicode, very long inputs. Only cases that could realistically occur.
3. **Error cases** — invalid input types or values. Assert on the error raised, not just that *something* raises.
4. **One regression test** — pick one bug a tired engineer might introduce while refactoring this, and write a test that would catch it.
Skip tests for behavior the function does not promise. No `test_returns_correct_type_when_passed_correct_type_obviously`.
Function:
```
[paste function here]
```
What you'll get back
One test file with clearly named tests grouped by category (happy / edge / error / regression). Each test has a docstring explaining what it asserts.
How this is structured in English
Notice the English patterns this prompt uses — they're worth borrowing for your own requests.
- Fail meaningfully when behavior breaks Defines what 'good test' means in concrete terms. Much more useful than 'high quality tests'.
- Coverage theater Industry slang for tests that exist only to raise coverage numbers. Using it here primes the AI to avoid that pattern.
- A tired engineer might introduce Specifying *who* might cause the regression makes the AI think realistically about failure modes, not just abstract bugs.