Insights26 January 2026Updated 25 October 20265 min read

Testing Strategies for Offline Scenarios: Ensuring Data Continuity

A glowing digital tree with circuit roots under a dome, displaying offline data continuity.

An offline test should prove what happened to a record, not merely that a screen stayed open without a connection. Our recommended starting point is a complete field task: capture an inspection, close the app, reopen it and reconnect. Check the record on the device and the server before calling the test a pass.

The distinction matters at the point where a request succeeds but its response never reaches the device. The HTTP specification describes retrying after this kind of communication failure, while distinguishing operations that are safe to repeat from those that are not. A reconnect test needs to exercise that uncertain outcome, rather than treating every timeout as a failed save.

Define what each success message promises

Before writing tests, agree what the app means by saved, pending and synchronised. We recommend reserving each label for a state that the test can inspect. A local save should have its own acceptance check, separate from the server accepting the change.

For a hypothetical inspection workflow, write down the expected record identifier, required fields, attachment references and current synchronisation state. Use those values as the expected result. Do not let the test derive its expectations from whatever the app happens to return.

Include rejected work in the specification. Decide what should happen when the device cannot store a new record, when an attachment is unavailable and when a server refuses an update. Require a visible explanation and a defined recovery action. Those are product decisions for the team to make, not behaviours to discover during release testing.

Interrupt the local save

For a browser-based app using IndexedDB, the W3C transaction rules require changes to commit together or not at all. The same specification identifies storage quota and input/output errors as possible transaction failures. That is a useful basis for testing the boundary between pressing Save and the app confirming success.

Our proposed checks are to interrupt the workflow before the transaction completes, after it completes and before the confirmation appears. Reopen the app after each interruption. Inspect whether the record and its queued upload agree, and whether the screen describes that state accurately.

For an inspection with photographs, make the attachment checks explicit. Require every displayed attachment reference to resolve to the expected file. Where a file is still uploading, require that state to remain visible. Treat a record marked complete with a missing required photograph as a failed acceptance test.

Repeat the storage-failure case with a controlled error in the persistence layer. The expected outcome should be a failed save, not a success message followed by an empty record after restart. Keep the real-device restart test separate from the simulated error test.

Lose the response after the server accepts the work

Test a successful server write whose response is deliberately withheld. Then allow the client to retry. Compare the resulting business records, not just the response code or the number of requests.

Amazon's approach to making retries safe uses a caller-provided request identifier to recognise repeated requests. This is one concrete design to test if your service uses an equivalent contract. Keep the identifier unchanged across a retry of the same operation. Give a genuinely new operation its own identifier.

For the hypothetical inspection, require the retry to leave one inspection with the intended values. Check separately whether the workflow created duplicate follow-up work. Make these expectations part of the service contract rather than assuming that a retry library prevents duplicate business effects.

Also test an interruption between sending different records. Upload part of a queue, restart the app and resume it. Require completed work to stay completed and outstanding work to remain available for retry.

Make two devices disagree

Use two devices or isolated test clients to edit the same starting revision. Reconnect them in different orders. Define the expected handling of each disagreement before running the test.

For HTTP APIs, If-Match provides a conditional update mechanism intended to prevent accidental overwrites. If your API uses it, test that an outdated revision cannot silently replace the current one. Verify the record afterwards, rather than treating a rejection response as sufficient proof.

Choose cases with different business meanings. Try independent field edits, competing edits to the same field and a deletion followed by a stale edit. Ask the product owner which changes may combine and which require a person to resolve them. Test the agreed answer, including what the user sees while a conflict remains unresolved.

Reconcile the business record

Murat Erder, Pierre Pureur and Eoin Woods distinguish database maintenance from checking application-level integrity across databases in Chapter 7 of Continuous Architecture in Practice. Their discussion suggests reconciliation as an explicit activity. That strengthens an offline testing strategy because it asks whether the application records agree, rather than stopping at the storage layer.

For our example, compare the inspection, its attachments and any resulting follow-up work against the expected outcome. Keep the test inputs, injected failure point and final records with the result. A screenshot alone should not be the acceptance evidence for synchronisation.

Automate the repeatable failure cases, then run the complete workflow on the supported devices. We recommend a release check that names the device, app version, interruption and observed final state. Start with the lost-response case if you have no such test today. It gives the team a precise question to answer: did retrying the same inspection create the intended result once?

Update, October 2026

For teams using agents to build these workflows, our engineering article on gated build loops describes independent review alongside tests and real-system verification. Apply that review to the expected offline outcomes as well as the implementation. Ask a fresh reviewer to challenge what the test proves before accepting its green result.

Sources

Want this in your team?

Tell us what you're building and where you want to get to, and we'll think it through with you.

Let's have a chat Follow by RSS →

All insights →