Generate unit tests that hunt the edge cases
Turns one function into a test suite that probes boundaries, bad inputs and failure paths - not just the happy path.
You are a senior developer writing unit tests for a small business codebase where bugs cost real money and there is no QA team.
<context>
LANGUAGE + TEST FRAMEWORK: [e.g. "TypeScript + Vitest"]
FUNCTION UNDER TEST: [paste the full function, including types and anything it calls]
INTENDED BEHAVIOUR: [plain words - e.g. "returns GST-inclusive total rounded to cents"]
KNOWN CONSTRAINTS: [e.g. "quantities can be zero but never negative; prices arrive as strings from the API"]
</context>
Before writing any test, enumerate the edge-case classes that apply to THIS function: empty/null/undefined inputs, boundary values, type-coercion surprises, rounding and precision, unicode or whitespace in strings, very large inputs, error paths, and ordering or duplication where relevant. Discard classes that cannot occur given the types, and say why.
Requirements:
1. One behaviour per test; name each test so a failure reads as a sentence about what broke.
2. Arrange-act-assert structure; no shared mutable state between tests.
3. Cover the happy path in at most 2 tests - spend the rest on the edge classes you listed.
4. Test observable behaviour, not implementation details (never assert on private internals).
5. Mock only true externals (network, clock, filesystem); show any mock you use.
6. Where intended behaviour is ambiguous for an edge case, write the test with your best-guess expectation and tag it // ASSUMPTION: so the owner can confirm.
<output_format>
The runnable test file first, then a short table: edge-case class -> covering test (or why skipped). Finish with anything you could not test without refactoring, and the smallest refactor that would fix it.
</output_format>
Grounding: use only the code and constraints provided; do not invent helper modules or fixtures that were not shown.
Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.
Want it tuned to your business? Bring it to the free weekly call and we'll adapt it live.
Join the free callMore coding & technical prompts
Keep a Two-Minute Daily Engineering Log That Pays Off Later
Turn end-of-day scraps into a structured log entry — decisions with their why, lessons, blockers — capped at 120 words and searchable months later.
Break a Stalled Decision With a Structured Tiebreak
Lay out the options, score them against your own criteria, price the delay, and get a verdict with a 48-hour commitment step — plus what would legitimately reopen it.
Engineer a Distraction-Proof Deep-Work Block
Set up a recurring focus block matched to your energy and team reality — device rules, a status script, an interruption protocol and a two-week bedding-in plan.