Edge Case Coverage
Systematically identify and handle boundary conditions.
Decision Tree: Which Edge Case Category?
What kind of edge case are you looking for?
├─ Input validation? → Check null, wrong type, empty, overflow, malformed
├─ Boundary values? → Check 0, 1, min, max, just-above, just-below
├─ State transitions? → Check uninitialized, concurrent, stale, partial
├─ Resource limits? → Check timeout, OOM, disk full, connection pool exhaustion
├─ Network failures? → Check offline, slow, partial failure, retry exhaustion
├─ Permission issues? → Check unauthorized, expired, revoked, insufficient scope
└─ Multi-system interaction? → Check race conditions, ordering, idempotency
Edge Case Categories
| Category |
Examples |
Detection Heuristic |
| Boundary |
0, 1, max, min, empty |
Any numeric or size parameter |
| Input |
null, undefined, wrong type |
Any external-facing function |
| State |
uninitialized, concurrent, stale |
Any stateful operation |
| Resource |
timeout, no memory, disk full |
Any I/O or long-running operation |
| Network |
offline, slow, partial failure |
Any remote call |
| Permission |
unauthorized, expired, revoked |
Any auth-gated operation |
Boundary Analysis
Numeric Boundaries
Value: age
├── Below min: -1
├── At min: 0
├── Just above min: 1
├── Normal: 25
├── Just below max: 119
├── At max: 120
└── Above max: 121
String Boundaries
Value: username
├── Empty: ""
├── Single char: "a"
├── Max length: "a" * 255
├── Over max: "a" * 256
├── Special chars: "user@#$"
└── Unicode: "user"
Error Scenario Template
## Scenario: [Name]
**Trigger**: [What causes it]
**Symptoms**: [What user sees]
**Root cause**: [Why it happens]
**Prevention**: [How to avoid]
**Recovery**: [How to fix]
Validation Checklist
Input Validation
State Validation
Coverage Matrix
| Input |
Valid |
Empty |
Null |
Overflow |
Malformed |
| Name |
[x] |
[x] |
[x] |
[x] |
[x] |
| Email |
[x] |
[x] |
[x] |
[x] |
[x] |
| Age |
[x] |
[x] |
[x] |
[x] |
[x] |
Anti-Patterns
- Happy path only — designing and testing only the expected flow; every production failure starts as an edge case someone assumed would not happen
- Ignoring nulls — null is the most common edge case in production; always handle explicitly
- Assuming valid input — external input is never trustworthy; validate at the boundary
- Missing timeout handling — every network or I/O operation must have a timeout; without one, the system hangs indefinitely
- Silent failures — swallowing errors without logging or surfacing hides bugs until they cascade
- Testing only one layer — edge cases at the integration boundary (API + DB, UI + API) are the most common production failures
- Forgetting idempotency — retries on failed operations cause duplicates if endpoints are not idempotent
When to Use
- Before implementing a feature — identify edge cases in the spec
- During code review — check for unhandled boundaries
- When hardening an existing system — systematic enumeration of failure modes
- When writing error handling — ensure all categories are covered
1---2name: edge-case-coverage3description: Identify and document boundary conditions, corner cases, error scenarios, and validation requirements that implementations must handle. Use when the user asks to find edge cases, identify corner cases, specify validation rules, enumerate error scenarios, harden a function against bad inputs, or think through what can go wrong at the boundaries of a system. NOT for writing the actual tests (use testing-framework or test-driven-development). NOT for structured risk registers around project-level risks (use risk-management). NOT for security vulnerability scanning (use code-review).4---56# Edge Case Coverage78Systematically identify and handle boundary conditions.910## Decision Tree: Which Edge Case Category?1112```13What kind of edge case are you looking for?14├─ Input validation? → Check null, wrong type, empty, overflow, malformed15├─ Boundary values? → Check 0, 1, min, max, just-above, just-below16├─ State transitions? → Check uninitialized, concurrent, stale, partial17├─ Resource limits? → Check timeout, OOM, disk full, connection pool exhaustion18├─ Network failures? → Check offline, slow, partial failure, retry exhaustion19├─ Permission issues? → Check unauthorized, expired, revoked, insufficient scope20└─ Multi-system interaction? → Check race conditions, ordering, idempotency21```2223## Edge Case Categories2425| Category | Examples | Detection Heuristic |26|----------|----------|---------------------|27| Boundary | 0, 1, max, min, empty | Any numeric or size parameter |28| Input | null, undefined, wrong type | Any external-facing function |29| State | uninitialized, concurrent, stale | Any stateful operation |30| Resource | timeout, no memory, disk full | Any I/O or long-running operation |31| Network | offline, slow, partial failure | Any remote call |32| Permission | unauthorized, expired, revoked | Any auth-gated operation |3334## Boundary Analysis3536### Numeric Boundaries37```38Value: age39├── Below min: -140├── At min: 041├── Just above min: 142├── Normal: 2543├── Just below max: 11944├── At max: 12045└── Above max: 12146```4748### String Boundaries49```50Value: username51├── Empty: ""52├── Single char: "a"53├── Max length: "a" * 25554├── Over max: "a" * 25655├── Special chars: "user@#$"56└── Unicode: "user"57```5859## Error Scenario Template6061```markdown62## Scenario: [Name]6364**Trigger**: [What causes it]65**Symptoms**: [What user sees]66**Root cause**: [Why it happens]67**Prevention**: [How to avoid]68**Recovery**: [How to fix]69```7071## Validation Checklist7273### Input Validation74- [ ] Required fields present75- [ ] Type correct76- [ ] Format valid (email, URL, etc.)77- [ ] Range within bounds78- [ ] Length within limits79- [ ] Characters allowed8081### State Validation82- [ ] Object initialized83- [ ] Resources available84- [ ] Permissions granted85- [ ] Dependencies met86- [ ] No conflicts8788## Coverage Matrix8990| Input | Valid | Empty | Null | Overflow | Malformed |91|-------|-------|-------|------|----------|-----------|92| Name | [x] | [x] | [x] | [x] | [x] |93| Email | [x] | [x] | [x] | [x] | [x] |94| Age | [x] | [x] | [x] | [x] | [x] |9596## Anti-Patterns9798- **Happy path only** — designing and testing only the expected flow; every production failure starts as an edge case someone assumed would not happen99- **Ignoring nulls** — null is the most common edge case in production; always handle explicitly100- **Assuming valid input** — external input is never trustworthy; validate at the boundary101- **Missing timeout handling** — every network or I/O operation must have a timeout; without one, the system hangs indefinitely102- **Silent failures** — swallowing errors without logging or surfacing hides bugs until they cascade103- **Testing only one layer** — edge cases at the integration boundary (API + DB, UI + API) are the most common production failures104- **Forgetting idempotency** — retries on failed operations cause duplicates if endpoints are not idempotent105106## When to Use107108- Before implementing a feature — identify edge cases in the spec109- During code review — check for unhandled boundaries110- When hardening an existing system — systematic enumeration of failure modes111- When writing error handling — ensure all categories are covered
viktorbezdek