An edge case is an uncommon but possible input that may break code or test a rule more deeply than ordinary examples. Good testing considers both expected everyday inputs and boundary conditions. section 6.2.1
Look for edge cases where data reaches a boundary, violates an assumption, or requires a special rule:
- Empty input, such as a list containing only empty strings or an empty list. section 6.2.1
- Boundary positions, including the first and last elements of a list. section 6.2.3 section 8.5
- Ties, where several inputs share the maximum and the specification determines which result to return. section 6.2.1 section 6.5.3
- Missing, zero, negative, repeated, or unexpectedly typed values. section 6.6.1 section 6.7
Finding a longest word
Suppose longest_word returns the longest item and keeps the first item when lengths tie. Test ordinary inputs such as ['a', 'bb', 'ccc'], then test ['cat', 'dog', 'me'] to check tie handling and ['', ''] to check empty strings. The tie test exposes an incorrect >= comparison that replaces the first result with a later equal-length word. These failures turn an informal expectation into an executable specification. section 6.2.1 section 6.2.3
>>> longest_word(['', '']) ''
Use the compact test-case listing to inspect how empty input, negative values, mixed types, and boundary-sized values become concrete checks. section 6.7
Design edge-case tests from the function's stated behavior, then inspect the implementation for assumptions that suggest additional tests. Run the failing case, form a hypothesis, debug the relevant path, correct the code, and rerun the full suite. Artificial datasets help test rare conditions even when real data does not contain them. section 6.5.3 section 8.5 section 6.6
