My tests passed on the obvious inputs and the app still broke in production. The obvious inputs are the easy ones. Bugs hide at the edges, so the skill is picking the cases at the boundary.
About 2 min of reading
Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.
Write the boundary and edge cases for a grading rule and let them expose an off-by-one.
A grade function with a boundary bug: it uses > where it should use >= at 60.
Before you run it, say out loud what it will print. Then open the answer.
Test exactly at the boundary. 60 should be D but the bug returns F, so this fails.
Before you run it, say out loud what it will print. Then open the answer.
Fix the comparison and the boundary test passes.
Before you run it, say out loud what it will print. Then open the answer.
The value just below still behaves as intended, confirming the boundary is now correct.
Before you run it, say out loud what it will print. Then open the answer.
Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.
For any threshold, test just below, exactly at, and just above. That triple catches off-by-one errors that a middle value cannot. The rule is not test more random values, it is test the values where the rule changes.
Empty, single, zero, None, negative, and the largest value are where code forgets a branch. A handful of edge tests finds more bugs than a hundred random middle cases, because the middle cases all exercise the same happy path.
assert first([]) is None
assert first([7]) == 7An empty list and a single item are edges. A function that works for three items often fails for zero or one. Test the counts at the boundary.
assert grade(59) == "F"
assert grade(60) == "D"If the rule says 60 is a D, test 59 and 60. A comparison written > instead of >= passes at 61 and fails exactly at 60. Off-by-one lives at the boundary.
assert count(None) == 0None, empty string, and zero are values that many functions forget. A test that names them catches the forgetful branch before production does.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.