Edge Case

An edge case is an input at the boundary of what a rule was designed for: the ride that crosses midnight, the order with zero items, the name with an apostrophe, the day a clock changes. It is not the same as a rare case. Edge cases are often common in real data and rare only in the examples people test with, which is why they survive into production.

A boundary input can cause a crash or a plausible but incorrect result. For example, a rule that wraps every duration into one day can silently shorten a two-day rental. Test both explicit failures and returned values: neither a successful return nor the absence of an exception proves the answer correct.

Several boundaries recur often enough to be worth a checklist: empty input and single-row input; zero, negative, and very large values; the first and last element; midnight, month ends, leap days, and clock changes; missing and duplicated keys; text with quotes, commas, and non-Latin characters; and units or currencies that differ between sources. Reading the data’s own extremes — minimum, maximum, counts by category — surfaces more of them than imagination does.

Specify the expected behaviour at each boundary. Identical clock readings without dates cannot distinguish zero hours from a full day; identical instants mean zero elapsed time. Decide whether a missing key should be rejected or represented explicitly as missing, and encode the decision in a test. Tests make the intended rule visible instead of leaving it to the next unexpected row.

References: Python unittest, pytest parametrized tests. See it in use in Researching Errors and Organizing Analytical Work.