Treat the option tuple as the product identity
Synthetic shop sells blue/small as SKU-BS and red/large as SKU-RL. Blue/large is not offered. Colour and size are both required. Selecting blue alone cannot default silently to small, and a visually similar item cannot replace an unsupported combination. The fixture defines only these two offered variants.
| Constraint | Required record | Example decision rule |
|---|---|---|
| Selection completeness | Colour + size | Both required before SKU mapping |
| Allowed combination | Offered tuple → SKU | Blue/small → SKU-BS |
| Unsupported choice | Explicit no matching SKU | Blue/large cannot become SKU-BS |
Test incomplete and unsupported choices
| Case | Input | Expected decision |
|---|---|---|
| Blue only | Size missing | Ask for size; no SKU selected |
| Blue / large | Not offered | Show unavailable combination |
| Red / large | Offered tuple | Select SKU-RL |
- Read complete option tuple
- Find exact offered mapping
- Keep missing or unsupported state explicit
- Pass selected SKU to order
A missing mapping after a catalogue edit needs review; it must not silently select the first item.
How many of the three shown selections produce a SKU?
Show the worked answer
One, red/large → SKU-RL. Blue-only is incomplete and blue/large is unsupported.
Keep the option-to-SKU map beside the requirement so a demo tests identity, not only a changing product picture.