In pairwise test generation, how do you handle forbidden parameter combinations?

## Why a raw cross-product model is usually a lie A parameter model written as independent lists implies that every value of every parameter can coexist with every value of every other. Real configuration spaces rarely honour that. In the quote engine model — product line, payment cadence, rating region, prior-claims flag, sales channel, discount bundle — two rating regions do not sell the umbrella product line at all, and the monthly cadence is not offered through the partner channel. Handing that model to a generator unmodified produces rows that cannot be set up, and a suite that cannot be set up gets quietly skipped, edited by hand, or marked as an expected failure until nobody reads the report. ## Constraints belong in the model, not in a post-filter The correct mechanism is to declare the exclusions as **constraints** before generation, typically as implications: `product_line = umbrella => region not in {R3, R6}`. Two things then happen. First, the generator never emits a row that violates the rule. Second — and this is the part candidates miss — the excluded pairs are removed from the set of pairs the array is *obliged* to cover, so the coverage report stays honest: it reports coverage of the reachable pair space rather than an unreachable ideal that will never hit 100%. Contrast the post-filter approach: generate 43 rows, notice that six of them are impossible, delete them, ship 37. Each deleted row was also carrying up to fourteen valid pairs across the other parameter pairings, and some of those pairs appeared in no other row. You have created uncovered pairs and, worse, no artefact records which ones. The set still looks like a covering array and is no longer one. If a generator you use cannot accept constraints, the salvage is to re-run coverage analysis over the surviving rows and append rows for whatever is now missing — not to ship the truncated set. ## Forbidden versus invalid: the distinction interviewers probe A **forbidden combination** is unconstructible: the system offers no path that produces it, so there is no behaviour to observe and nothing to assert. It goes in the constraints. An **invalid input** is constructible and must be rejected. A prior-claims flag set on a product line that does not price claims history is not impossible to submit; it is something the quote engine must refuse with a specific message. Constraining it away deletes a whole class of negative testing. The test for which category you are in is simple: can a user or an upstream caller cause this state? If yes, it is not forbidden, and the covering array should carry it. There is a third category worth naming: combinations that are *possible but out of scope for this run* — a legacy channel being retired at the end of the 3-week release train, say. Model those as a temporary constraint with a note and an expiry, not as a permanent fact about the domain, or the constraint outlives its reason and quietly shrinks the matrix forever. ## Second-order effects of constraints Adding constraints does not always shrink the output. Exclusions break up the packing: values that used to travel together in one row now cannot, so the generator needs extra rows to place the pairs it can no longer combine. Seeing a row count rise from 43 to 47 after adding four constraints is normal and is not a bug. Heavily constrained models also risk **infeasible pairs** — a pair that every constraint set forbids in combination with something else, so it can never appear. A good generator reports these explicitly. If your tool does not, sanity-check the coverage report against the declared pair count rather than trusting a bare "100% covered" line. Where constraints become dense, an alternative is to split the model into **sub-models**: one parameter set for the personal product lines, another for commercial, each internally consistent, each generating its own array. Two clean arrays are easier to defend and to regenerate than one model carrying twenty implications, and the union usually costs fewer rows than the constrained single model. ## Practical hygiene Keep constraints in the same versioned file as the parameter model so a reviewer can see the domain rules and the value lists together. Write each constraint with a one-line reason; "region R3 has no umbrella licence" survives a re-read months later in a way that a bare exclusion does not. Re-derive the array when the rules change rather than patching rows by hand, and diff the generated set so you can see which configurations entered and left the suite. And treat a constraint that suddenly makes many rows infeasible as a signal that the domain changed, not that the generator misbehaved.