| name | edge-case-generation |
| description | Systematic edge-case identification including boundary values, null inputs, type mismatches, and error path testing.
|
Systematic edge-case generation for thorough test coverage.
When to activate
Use this skill when generating tests for any function or module -- always
consider edge cases alongside the happy path.
Boundary values
- Min and max integers (0, -1,
sys.maxsize, Number.MAX_SAFE_INTEGER).
- Empty string
"", single-character string "a", very long strings.
- Empty collections:
[], {}, set().
- Zero, negative numbers, very large numbers.
- Single-element collections -- many off-by-one bugs surface here.
- Boundary of valid ranges: if a function accepts 1--100, test 0, 1, 100,
and 101.
Null/None inputs
None (Python) or null/undefined (JavaScript) for every parameter
that could receive them.- Missing dictionary or object keys.
null values inside JSON payloads.- Optional parameters omitted vs explicitly set to None/null.
Type edge cases
- Wrong types passed to loosely-typed functions (string where int expected).
- Unicode strings with emoji, RTL characters, zero-width joiners.
- Special characters: newlines, tabs, null bytes, path separators.
NaN, Infinity, -Infinity for numeric inputs.- Very long strings (10k+ characters) to surface truncation or memory bugs.
Error paths
- Invalid arguments that should raise/throw.
- File not found, permission denied, directory instead of file.
- Network timeout, connection refused, DNS resolution failure.
- Malformed input: invalid JSON, broken XML, truncated data.
- Division by zero, integer overflow.
Concurrency
- Race conditions when two calls happen simultaneously (if applicable).
- Concurrent reads and writes to shared state.
- Reentrant calls -- calling a function while it is already executing.
Methodology
For each function parameter:
- List the valid range.
- Test the first valid value, the last valid value, and one value just
outside each boundary.
For each branch in the function:
- Ensure at least one test exercises that branch.
For each exception or error the function can raise:
- Write a test that triggers it and verifies both the type and the message.
MUST
- Test empty inputs for every function that accepts collections or strings.
- Test the first and last valid values of every bounded parameter.
- Test error messages, not just error types -- verify the message is helpful.
MUST NOT
- Do not generate edge cases that are unreachable given the function's type
signature and call sites.
- Do not test implementation details -- edge cases should exercise the
public API contract.
- Do not write brittle tests tied to exact error message wording -- use
substring or pattern matching when messages may evolve.
