Find untested edge cases for a module before writing any tests
Category: Testing · Updated 2026-09-22 · Tools: Claude Code
Use this on a module you suspect is under-tested for edge cases specifically — happy-path coverage exists, but you're not confident about what happens at the boundaries. Best run as a two-step conversation: gap list first, tests second, so you're not paying for tests aimed at edge cases that don't actually matter for this code. Small to medium usage for the gap-finding step.
Full prompt
Read through <module/file path> closely, including its existing tests. List every edge case you can identify that isn't currently covered by a test: empty or null input, boundary values (zero, negative, max size), malformed or unexpected input shapes, concurrent/repeated calls if relevant, and any implicit assumption the code makes about its callers that isn't enforced in code. For each one, give a one-sentence description of what could actually go wrong if that case isn't handled correctly, and rate how likely that case is to occur in real usage (common/rare). Do not write any test code yet — wait for me to tell you which items from the list to turn into tests.
Tips
- Reviewing the list before any test gets written avoids spending usage on edge cases that turn out to be irrelevant for how the module is actually called
- Ask for the "common vs. rare" rating explicitly — it's the fastest way to triage a long list down to what's worth testing first
- Point the agent at a single module rather than the whole codebase, or the list becomes too broad to act on in one sitting
Still waiting on a reset? See what to do when you hit the limit, or check Codex / Claude time since last reset.
Back to the prompt library · Subscribe: all-products feed