Happy-path tests are easy to write. Edge cases are the ones that bite you in production — and Claude is good at thinking of them.
After writing your core tests, share the function or method and ask:
Here's my validatePayment() function and its current tests.
What edge cases am I missing? List them, then write the
missing test cases.
Claude will think through boundary conditions, null inputs, concurrency issues, off-by-one errors, and domain-specific gotchas you might not have considered:
Edge cases you haven't covered:
1. Amount is exactly 0 — should this be rejected?
2. Currency code is an empty string vs null
3. Decimal precision beyond 2 places (e.g. 10.999)
4. Negative amounts
5. Integer overflow on very large amounts
6. Currency codes that are valid ISO 4217 but not supported by your processor
This works especially well for security-sensitive code — authentication, file uploads, form validation — where the failure modes aren't obvious from the function signature alone.
You can push further and ask Claude to rate each edge case by severity or likelihood so you know which ones to prioritise first.
You write the happy path — let Claude be the adversarial tester.
Log in to leave a comment.
Before asking Claude to scaffold a new feature, point it at your existing code first — it will match your naming, structure, error handling, and test patterns exactly rather than defaulting to framework boilerplate.
Give Claude the full picture upfront before it writes any code, so it builds the right thing the first time with fewer correction rounds.
Complex prompts are unreadable as escaped single-liners. Use shell HEREDOCs to write clean, structured prompts directly in your scripts.