When is the upkeep of a behaviour-model test suite no longer worth it for a small team?

## The investment framing A behaviour model is not a test; it is an asset with three cost lines. **Build**: the abstraction decision, the model, the adapter, the harness. **Carry**: every product change that touches modelled behaviour also costs a model edit, a review and often an adapter change. **Triage**: every failure needs sorting into system fault, model fault or adapter fault before anyone can act. The build cost is visible and gets estimated; the carry and triage costs are invisible at the decision point and are what actually kill the effort. So the question is never "is model-based testing good?" but "does this system, with this team, at this rate of change, return more than the carry?" ## What drift actually is Drift is the model and the system diverging while the suite continues to run. It is insidious because a drifted model does not go silent — it keeps producing green runs about behaviour that no longer exists, and red runs about behaviour that changed deliberately. Each such red costs triage and returns nothing, and the team learns to distrust the signal. The usual mechanism is asymmetric pressure. Shipping is urgent, the model is not, so a rule changes in the product on Tuesday and the model gets it on some later Tuesday, or never. Once the gap is wide enough that a model edit is a small project rather than a small change, the technique has already failed; what remains is deciding when to say so. ## The four signals **Edit ratio.** Track model edits against product changes touching modelled behaviour. A healthy model absorbs a change in one small, reviewable edit. When a routine change needs restructuring the state machine, the abstraction was wrong — usually too fine, so the model has become a second implementation with its own defects. **Triage mix.** Tag every failure by culprit. Early on, roughly one genuine defect for every two or three model or adapter faults is normal and should improve. When the ratio moves the other way over a quarter, the suite is generating work rather than findings. **Quarantine.** Generated paths being skipped rather than reconciled is the clearest terminal symptom. A quarantined generated path cannot be fixed in isolation, because it was derived — skipping it means the model is wrong and nobody has time to say how. **Ownership.** A 4-person team is the interesting stress case. If the model's original author owns every edit, three of the four are blocked whenever behaviour changes, and the model outlives its author's tenure by weeks. Models die of a bus factor of one more often than of any technical cause. ## Measuring rather than arguing The metric worth defending is **genuine defects found per maintenance hour**, compared against what the displaced hand-written cases were returning, with two adjustments. Count the defects the technique is uniquely able to find — order-dependent and long-sequence faults — rather than the ones any smoke case would have caught. And count the model as documentation value if, and only if, someone outside the team actually reads it; most teams claim this benefit and cannot name a reader. Run time belongs in the same conversation. When the billing model grew from 9 states to 34 states and 88 transitions, the nightly generated run reached 71 minutes, which changed who was willing to wait for it and therefore how quickly drift got noticed. A suite people do not wait for stops being a feedback loop and becomes an archive. ## Keeping it alive when it is worth keeping Coarsen deliberately: fewer, more meaningful states, with detail pushed into state invariants rather than new states. Make the model part of the definition of done for any change to modelled behaviour, reviewed in the same change rather than followed up. Spread authorship — pair on the first few edits until every engineer has made one. And bound the generated set with an explicit time budget so growth is a visible decision rather than a slow slide. ## Retiring it well Retirement is a legitimate outcome, not an admission of failure, and doing it badly is worse than not starting. Freeze the model rather than deleting it silently. Take the generated paths that have historically caught real defects — usually a small fraction — and promote them to ordinary hand-maintained cases with the intent written into their names, so the accumulated knowledge survives. Then delete the generator and the adapter, because a half-maintained generation pipeline is exactly the kind of artefact a future engineer will neither trust nor dare remove. ## What an interviewer is listening for That you treat this as a portfolio decision rather than a technology preference: which systems in an estate justify a model at all, who carries it, what evidence would make you stop, and what the exit looks like. Confident advocacy with no exit criterion is the answer that fails; so is dismissal of the technique on the strength of one team's bad adapter.