Equivalence Partitioning (Lab)
A hands-on lab: split an input space into classes the system should treat identically, then test one representative from each class instead of every possible value.
What you'll learn
- Partition an input space into valid and invalid equivalence classes
- Choose one representative test value per class
- Explain why testing every value in a class adds cost without adding confidence
Prerequisites
Explanation
Equivalence partitioning rests on one assumption, and it's worth stating explicitly because the whole technique depends on it: if the system treats one value in a group correctly, it will very likely treat every other value in that same group the same way. Testing a shipping-cost calculator with an order of $50 and $51 separately, when both fall in the same "standard shipping" bracket, tells you almost nothing that testing $50 alone didn't already tell you. The two inputs are equivalent from the system's point of view.
The technique has two steps. First, partition: divide the entire space of possible inputs into classes where every member of a class should be handled identically. For a discount code field that requires exactly 6 alphanumeric characters, the classes might be: too short, too long, right length but contains an invalid character, and right length with all valid characters. Notice there are usually multiple invalid classes, not just one big "invalid" bucket — "too short" and "contains a symbol" are different kinds of invalid and might be handled by different code paths, so they deserve separate test cases.
Second, select one representative per class. Testing "abc123" as the one valid-class representative and "ab1" (too short) and "abcdef!" (invalid character) as invalid-class representatives gives you meaningful coverage of the whole space with just three test cases — instead of testing hundreds of individual six-character strings that would all exercise the exact same code path.
The most common mistake is forgetting the invalid classes entirely and only testing "happy path" valid inputs. A discount-code field that correctly accepts "abc123" but crashes on a 3-character input hasn't been tested at all on its most realistic failure mode — real users mistype far more often than they type perfectly.
Example
A shipping-cost rule with three price bands, tested with one representative value from each equivalence class rather than every possible price.
function shippingCost(orderTotal) {
if (orderTotal < 25) return 9.99; // class: below free-shipping threshold
if (orderTotal <= 100) return 4.99; // class: standard reduced shipping
return 0; // class: free shipping
}
console.log(shippingCost(10)); // representative of "below threshold"
console.log(shippingCost(50)); // representative of "standard band"
console.log(shippingCost(150)); // representative of "free shipping"Try it yourself
Add a fourth class the function doesn't currently handle explicitly (negative totals) and predict what happens before running.
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Guided exercise
Guided exercise
A username field requires 3 to 12 characters. Choose one representative value (a string) for each class: tooShort (fewer than 3 chars), validLength (3 to 12 chars), tooLong (more than 12 chars).
Checks: tooShort is a valid representative of the too-short class · validLength is a valid representative of the valid class · tooLong is a valid representative of the too-long class
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Independent exercise
Independent exercise
A discount code must be exactly 6 characters, using only letters and digits (no symbols). Design representatives for FOUR classes: tooShort, tooLong, rightLengthWithSymbol (6 chars but includes a symbol like ! or -), and valid (6 alphanumeric chars).
Checks: tooShort represents the too-short class · tooLong represents the too-long class · rightLengthWithSymbol represents the right-length-but-invalid-character class · valid represents the valid class
Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.
Stuck? Get a hint.
Common mistakes
- Lumping all invalid inputs into one test case instead of recognizing that different kinds of invalid input often exercise different code paths.
- Choosing multiple representatives from the same class (e.g. testing three different valid lengths) instead of moving on to test a different class.
- Forgetting that equivalence partitioning covers valid classes as thoroughly as invalid ones — a system that handles bad input well but mishandles some valid input is just as broken.
Knowledge check
Takeaway
Equivalence partitioning turns an unmanageable input space into a small set of classes, each needing just one representative test — with invalid input deserving as much careful classification as valid input.
Summary
This lab practiced dividing input spaces into valid and invalid equivalence classes and choosing one deliberate representative test value per class, rather than testing exhaustively or guessing.
References
Your notes
Notes save automatically.
Finished this lesson?
Mark it complete to track your progress and schedule a future review.
AI tutor
The optional AI tutor isn't enabled in this deployment. All lessons, exercises, quizzes, and search work fully without it.