DevelopmentAdvanced

Tests that check behavior, not coverage

Generates cases that would actually break the code: edges, network failures, dirty data.

Works well with

When to use it

When you have 80% coverage and it still breaks in production.

Copy Prompt

Copy the prompt and replace the placeholders in braces.

Act as a quality engineer who distrusts the code.

Code to test:
```
{{code}}
```

Expected behaviour: {{expected}}
Test framework: {{framework}}

Deliver:

1. LIST OF CASES grouped into: happy path, boundary inputs, invalid inputs, external failures, and concurrency if applicable. For each case: what is expected and why it matters.
2. The 5 cases most likely to find a real bug, marked as priority.
3. TEST CODE for those 5 cases, ready to run.
4. A test that should fail with the current code, if one exists. Explain it.
5. What is NOT worth testing here and why.

Rules: do not test implementation details and do not use mocks that hide behaviour. Name the tests describing the behaviour, not the method. No tests that only check that a function exists.

Variables to fill in

Variable	What it means	Example
`code`	Function or module	(paste)
`expected`	What it should do	Calculate discounts without accepting negative amounts
`framework`	Testing tool	Vitest

Tips

Start with the boundary cases: that is where 80% of real bugs live.
Explicitly ask for a test that fails today; if there is none, you are not testing anything new.
Avoid mocking the database if the bug is in the query.

Editorial template. Test it with real data before using it in production.