Why should each invalid equivalence class get its own test case rather than one combined case?

## The masking problem Equivalence partitioning tells you to test one representative per class. The moment you have several fields, a practical question follows: how many classes may one test case cover? The answer is not symmetric between valid and invalid classes, and the asymmetry is the whole point of this question. Consider a booking request to a hospital appointment scheduler carrying a lead time in days, a clinic code and a referral identifier. Suppose you want to cover two invalid classes: lead time below the accepted minimum, and a clinic code that does not exist. It is tempting to send one request with both, see it refused, and tick off two classes with one case. That case will almost certainly pass. It will also almost certainly have tested only one of the two classes. Validation is usually **fail-fast**: the handler checks the lead time, finds it out of range, returns *requested too soon*, and never looks at the clinic code. The unknown-clinic rule could be missing, misspelled or wired to the wrong message and your suite would stay green. The second class was **masked** by the first. Worse, the masking is order-dependent: reorder the validation checks during a refactor and the test silently starts covering the other class instead, without anyone noticing that it changed meaning. ## The rule Design one test case per invalid class. In that case, the field under test carries a representative of the invalid class; **every other field carries an ordinary valid representative**. Nothing else in the request is allowed to be a reason for refusal, so if the request is refused, it is refused for the reason you are testing. Valid classes are the mirror image. To be accepted, an input must satisfy every rule at once, so a single accepted request necessarily lands in one valid class per field, and packing several valid classes into one case costs you nothing in diagnosis — the case is expected to pass, and if it fails you have a small number of fields to look at. This is why a partition-derived suite typically has relatively few positive cases and one negative case per invalid class. ## Assert which rule fired The rule about one invalid class per case only pays off if the assertion is specific. A case that asserts *the request was refused* is satisfied by any refusal, including a refusal produced by a rule you did not intend to exercise. Pin the assertion to the identity of the violated rule — the machine-readable reason code, the field the message points at, the error category — so that a check firing for the wrong reason is a failure rather than a pass. In the scheduler, *requested too soon* and *beyond the booking horizon* are two classes with two reason codes; a suite that asserts only refusal cannot tell you that the two were swapped. Assert the absence of effects too. A rejected booking must not create an appointment, hold a slot, or send a confirmation. A rejection test that checks only the response can pass while a partially applied write has already happened, and that is a defect the negative case is in a perfect position to catch. ## When the rule relaxes Some systems are specified to collect all violations and report them together rather than stopping at the first. There the masking risk is much smaller, because both rules genuinely run. Two cautions remain. First, that behaviour is a specification claim, and the case that proves it — one request violating two rules, asserting that both reasons come back — is a test in its own right, not a licence to fold every invalid class into one case. Second, collecting violations is often only partial: cheap structural checks may be batched while an expensive lookup, such as verifying the clinic code against a registry, still short-circuits. If you fold classes together on an assumption about ordering, the suite starts depending on an implementation detail that nobody promised to keep. ## What it looks like in practice Suppose the scheduler's specification yields six invalid classes across three fields. The disciplined suite is six negative cases plus a small number of positive ones, and each negative case names the rule it is about. The tempting shortcut is two or three combined cases, which reads as a smaller, tidier suite and gives you the coverage of maybe two rules. The count is worse the other way round: the combined suite is smaller **and** covers less, which is the rare case where the tidier artefact is strictly the weaker one. Keep the negative cases boring, one reason each, and the day a validation rule is accidentally deleted, exactly one test goes red and its name tells you which rule it was.