Mine Claude for the Edge Cases You Missed

A testing pattern where, rather than asking Claude to write tests, you first ask it to enumerate the edge cases and failure modes of a function — then decide which deserve tests. It's using Claude as an adversary against your code, not a scribe.

You test the cases you thought of, which are the cases you already handled — that's why your tests pass and production still breaks. Claude has seen thousands of ways similar functions fail, so it surfaces the empty inputs, boundary values, unicode, timezone, and concurrency cases you skipped. Separating enumeration from writing keeps you in control of what's worth covering.

Before finalising tests for anything with non-trivial inputs — parsers, validators, date math, money, anything touching user data or external systems. Also great when coverage is high but bugs still slip through.

Trivial pure functions where the input space is tiny and obvious. Enumerating edge cases for add(a, b) is busywork.

Here is a function and its current tests: <paste>.

Don't write tests yet. First, list the edge cases and failure modes this function could hit that the current tests don't cover — empty/null/boundary inputs, malformed data, concurrency, locale, overflow, whatever applies. Rank them by how likely they are to bite in production. Then I'll pick which ones to turn into tests.

For a date-range function your tests cover the happy path. Claude's list flags: start after end, a single-day range, a range spanning a daylight-savings change, and a null end. The DST case is one you'd never have written — and it's exactly the one that would have paged you.

Have Claude generate a property-based test that asserts an invariant across randomised inputs ("the output is always sorted", "parsing then serialising is identity") instead of a fixed list of cases. Properties catch whole classes of edge cases you'd never enumerate by hand.

• Turning every suggested edge case into a test — some aren't worth the maintenance; you choose, not the list.
• Asking for the tests directly and skipping the enumeration, which is where the value is.
• Testing edge cases the function is explicitly documented not to handle, locking in behaviour you don't want.