A disconnected screen still renders records loaded earlier - how does a case tell stale-but-allowed from simply wrong?

A screen that renders with no connection is doing one of two very different things: serving data the device legitimately holds, or inventing something. Telling those apart is the entire job of the case, and it cannot be done by comparing the screen with the far side - because on a disconnected client, the screen and the far side are *supposed* to disagree. Compare them and every correct stale read turns red, the team stops believing the case, and it gets deleted or slackened until it catches nothing. ## The oracle is the captured snapshot Before the link is taken away, drive the device into a known state: sign in, let synchronisation settle, and record the exact values the device now holds. That recording is the oracle for everything that follows. Depending on the product it may be the rows read off the screen, a projection the case can query, or the payload the device was last served. What matters is that it is captured while the link was up and kept inside the case. Only then disconnect, and only after disconnecting change the same records on the far side through a service interface. You have now manufactured, on purpose, the situation the retained-read behaviour exists to handle: the device is behind and has no way of knowing it. ## Five renderings, five verdicts | What the disconnected screen shows | Verdict | Why | | --- | --- | --- | | The captured snapshot, marked as not current | Pass | Exactly the retained-read promise | | The captured snapshot, rendered as if live | Fail | The user is told something false | | Values only the far side could know | Fail | Impossible; investigate the harness first | | Nothing, where retention was promised | Fail | The promise was not kept | | A defined empty state, where nothing was promised | Pass | Honest about what it does not hold | Rows four and five are the same rendering with opposite verdicts, which is why the expectation has to be settled before the case is written. Blank is a defect only against a promise; with no promise on record the case has no ground to stand on. Getting that promise written down is often the most valuable half-hour of the work, and it is a conversation, not a test-design decision you can make alone. ## The freshness cue is part of the pass, not decoration Stale data presented as current is worse than no data, because the user acts on it. So the assertion is not only *what* is rendered but *how it is labelled*: a timestamp of the last successful update, a banner, a distinct treatment with an accessible label - whatever the design chose. Two failure shapes are worth naming explicitly: - **The cue never appears.** The user believes a figure that is hours old. Nothing crashes, no error is logged, and only an assertion on the cue catches it. - **The cue never clears.** Once the link returns and fresh data arrives, a lingering warning teaches users to distrust data that is now correct. Assert the return path as well as the outage. ## Writing it so it stays green for the right reason 1. **Seed the records through a service interface** with values the case chose, so the snapshot contains recognisable strings rather than whatever the shared account happened to hold. 2. **Assert the snapshot is non-empty** before disconnecting. A case where both sides are empty passes for no reason at all, and this is the single most common way this case rots. 3. **Force a real read, not a redraw.** Navigate away and back, or reopen the application, so the screen genuinely resolves data with no connection rather than showing what was already in memory. 4. **Assert the exact fields you seeded**, not a row count. A count matches while every value is wrong. 5. **Restore the link and assert convergence** - the newer values appear and the cue clears - so the case covers the recovery as well as the outage. ## What this case does not own How much is retained, in what order it is discarded when space runs short, and when the device decides its copy is too old to serve are design questions with their own home. This case does not choose a retention policy; it takes the stated one and asks three things of the product: are the reads the design promised actually served with no connection, are they labelled honestly while they are old, and do they give way to fresh data once the link returns. Those three hold their value even if the storage layer underneath is replaced entirely, which is what makes them worth automating on a handheld where the outage is a normal condition rather than an incident.