During a recent job interview, I was asked to write some code -- I know, shocking! The idea was that several test cases had been defined, and that I was to implement a relative simple class that would make the tests pass. The problem was pretty simple, so I won't bore you with it.
What was shocking, however, was how poorly designed the tests were. Boundary cases were largely untested, and it seemed like someone spent an inordinate amount of time writing useless tests. When I brought this up during the interview, the person who wrote the tests seemed surprised that they weren't very good, because he got nearly 100% code coverage on the implementation he created.
While code coverage is all fine and dandy, it doesn't actually say anything about the quality of your tests. Maybe his implementation would've worked perfectly, even with strange values and edge-cases. Maybe not. We'll never know.
Equivalence Partitioning is one of the simplest test-design techniques. As the name pretty much implies, the idea is to partition possible input values into equivalent classes. Sounds like a bunch of gibberish? Let me illustrate with a classic example. Liquor laws.
As you can tell from the image, if you're under 16, you're not allowed any alcoholic beverages. Once you turn 16, you're allowed to have beer and other non-spirits. Once you turn 18, you hit the jackpot and can drink whatever tickles your fancy.
The red, yellow and green areas are the three Equivalence Classes for this problem. Whether you're newborn, 5, 11 or 15, it doesn't matter, you're not getting a drink. And once you're older than 18, your age stops mattering entirely.
Once you have this information, you can design a couple of test cases. In this case, you could start off by designing a test case for each class. The exact age for each test you pick doesn't matter, as long as it's in the class you're testing – or outside of it if that's what you're testing.
So that's three easy tests. Then it's time to apply a bit of Boundary Value Analysis. After all, it's so very easy to create off-by-one errors.
Boundaries are the areas where equivalent classes meet. The boundaries in this case are 16 and 18. When you look at the boundaries you've defined, you'll want to look very carefully at your specifications again. Someone's just turned 16 on this very day. Does that mean they can have a drink? Or not? Once you have the answer, create a test case. Then do the same for all other boundaries.
With five test cases, one for each boundary and one for each equivalence class, you'll have tested this very thoroughly. Additional test cases can be made to test invalid input. What happens if you try to pass a person with a negative age? What if the age is a million years old?