Generate unit tests that hunt the edge cases

Coding & Technical Claude advanced

Turns one function into a test suite that probes boundaries, bad inputs and failure paths - not just the happy path.

When to use it: When code works in the demo but you don't fully trust it, or before refactoring a function nobody wants to touch.
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 call

More 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.