A 340-case screen-driven pack checks every fare-calculation combination through the screens; which of those checks belong at a lower level?

### The symptom and the real question A pack of 340 screen-driven cases against a public-transport fare calculator has grown one case per fare combination: zone pairs, peak and off-peak bands, concession types, weekend rules. It now takes over an hour, and on a busy machine the parallel workers exhaust the available memory and the run dies partway through with no verdict at all. The tempting fixes are operational - more workers, fewer workers, more memory. They are worth doing, but they answer the wrong question. The real question is **what each of those 340 cases is claiming**, and whether a screen is required to make that claim. ### Sorting by claim, not by feature Write down, for a sample of cases, the sentence the case would let you say if it passed. Three groups appear. **Claims about a rule.** "A senior concession on a peak zone-2-to-zone-5 journey costs 3.40." The screen contributes nothing here. The rule lives below; a case at that level runs in milliseconds, takes a table of combinations, and names the failing row. Two hundred-odd of the 340 are usually this group. They are the ones to move. **Claims about wiring.** "Choosing zone 5 as the destination and 08:12 as the departure produces a request for a peak zone-2-to-5 fare, and the answer is displayed to the rider." This one needs the screen: it is about controls being connected to the right inputs, the result being rendered, the formatting being right, and the states in between existing. One or two cases per screen usually cover it, because the wiring either works for all combinations or is broken for all of them. **Claims about a journey.** "A rider can plan a trip, apply a concession and buy the ticket." Genuinely end to end, genuinely valuable, genuinely expensive. Cover each critical journey **once**, at full length, and resist the urge to re-walk it with a different concession type - that variation is a rule claim wearing a journey costume. ### What stays at screen level - The critical journeys, once each. - Wiring of each significant screen: inputs reach the system, the result comes back and is displayed. - Behaviour that only exists on the screen: a control disabled until a selection is made, an error surfaced in the place a rider would look, a state reachable only through interaction. - A small number of cases over things that historically break only when assembled - and be honest that this is a judgement call, not a rule. ### What moves down - Input combinations against a rule or a table. - Validation of a single field's accepted values. - Formatting, rounding, currency and locale variants. - Error mapping - which condition produces which message - once one case proves the message reaches the screen. - Anything whose expected result you can compute without rendering anything. ### Doing the move without losing coverage The failure mode of this work is deleting the screen case before the lower-level one exists, or writing a lower-level case that quietly checks something weaker. So: 1. **Measure first.** Per case: run time, failure history, and what it has ever caught. A case that has never failed in a year of runs, and whose rule is checked below, is not protecting anything. 2. **Write the replacement first**, run both for a while, and confirm the lower-level case fails when you break the rule on purpose. Then, and only then, retire the screen case. 3. **Move a slice at a time** - one rule family per change - so a coverage regression is attributable. 4. **Say what you traded.** The moved cases no longer prove the rule is reachable *through the screen*. That is exactly why one wiring case per screen has to stay, and why it must assert the displayed value rather than merely that the screen loaded. ### The counter-arguments to take seriously Someone will say the screen pack is the only thing that tests what the customer really does. Half true: it is the only level that exercises assembly, and that is why the journeys and wiring cases stay. It is not true that a rule is better checked through a screen; it is checked more slowly and less precisely, and the failure names a screen rather than a rule. Someone else will say the lower level cannot be trusted because it uses stand-ins for its neighbours. That is a real risk, and the answer is to be specific about which claim each level makes - the screen proves the pieces are connected, the lower level proves each piece is right - rather than to duplicate the whole matrix in both places. And expect a version of the argument that a run failing on resources should be fixed by capacity alone. Capacity buys time; it does not stop a pack that grows one screen case per rule variant from arriving at the same wall again with more cases and a longer feedback delay. The composition change is what holds.