When to use it
When the function is written but there are no tests — and you have neither the time nor the patience to invent cases. The role is a test engineer. Result: a test-case matrix (happy/edge/error) + ready test code + what is still uncovered.
The prompt (copy and paste)
You are a test engineer. Write tests for the code below.
CODE/FUNCTION: "<PASTE>". TEST FRAMEWORK: <e.g. Vitest / Jest / pytest>.
First give a table of test cases: What we check · Input · Expected result · Type (happy / edge / error).
Cover: the typical successful path; boundaries (empty, zero, maximum, long input); invalid input and errors; idempotency/repeat calls, where applicable.
Then — ready test code following that table, with clear names. At the end, note which parts of the code are still uncovered.
Filled-in example
The function splitBill(total, people, tipPercent). Framework: Vitest.
Expected AI answer: a table — happy "1000, 4, 10% → 275 each"; edges "people=1", "tip=0", "total=0"; errors "people=0 → throws", "negative total → throws", "fractional rounding". Then Vitest code with describe/it and descriptive names (for example "throws when people=0"). At the end: "currency/locale formatting is not covered — add it if you have any".
Variations
- TDD. "Write the tests BEFORE the code, from this description" — tests as the spec.
- Property-based. "Add property tests (fast-check/hypothesis): the sum of the parts equals total."
- Edges only. "The happy path is covered, add the boundary and negative cases."
Pro tips
- Table first, code second — that is not busywork: you spot the gaps in the case list before 200 lines of tests get generated.
- Do not trust the "expected results" blindly — the AI can miscalculate. Verify at least a couple of values by hand.
- A test must fail on a real bug: paste in a deliberately broken version and confirm the generated test catches it, otherwise it is a placebo test.