Edge case
Why it matters
Each edge case is rare. Together they are common, because a product with thousands of users meets dozens of them every week. The common path builds the product, and the edge cases build trust. A customer who hits a form that silently does nothing does not think "rare situation". They think "this is unreliable". Fixing one after a support ticket costs far more than deciding in advance what should happen.
How to apply it
- List the boundaries of each input and state: empty, zero, maximum, negative, duplicate, very long, and unusual characters.
- Rank them by how likely they are and how much damage a bad result would do. Money, personal data and anything irreversible come first.
- Decide the correct behaviour for each, instead of letting the system fail in whatever way was easiest to code.
- Write an automated test for each case that matters, so a later change cannot quietly break it. See test coverage.
- Read support tickets for cases nobody anticipated and add the worst to the list.
What it is
Most users do roughly the same thing, and software is built around that. An edge case is what happens at the boundaries. A customer with no orders yet, a surname with an apostrophe or accent, a quantity of zero, a form submitted twice by a nervous double-click, a booking at midnight across time zones, an invoice dated 29 February. Strictly, a "corner case" is two unusual conditions at once, but the two terms are used interchangeably.
When building with AI
Code generated by an AI assistant usually handles the happy path well. Ask it directly to list the edge cases of a feature and to write tests for them before accepting the result.