How Do You Test a Feed Refresh Failure?
From the earlier reference collection. Read the current software blog.
Simulate a failed refresh and verify that last-known data remains visible with an honest status label.
Set up a successful prior refresh
A refresh failure test needs something worth preserving. Begin with a successful feed response containing a recognizable record and its observation or retrieval time. Render the interface and confirm the data is present. Then make the next refresh fail through a controlled fake source, such as a timeout or server error.
The expected result is usually that the last-known data remains available while the interface communicates that the latest refresh did not succeed. The precise label and retry behavior depend on the product contract; encode those outcomes explicitly.
Check data and status separately
After the simulated failure, assert that the prior value has not been cleared or replaced with fabricated defaults. Separately assert a visible status such as “refresh failed” or “showing previous data,” along with the age or timestamp if the interface provides it. A preserved number without context can mislead someone into thinking it is current.
Also verify that the failed attempt does not advance the successful-update timestamp. If the interface has both fetch time and observation time, keep the meanings distinct: a recent fetch can still contain an old observation.
Cover first-load failure
A failure before any successful response has no last-known value to preserve. Test that case separately and expect an unavailable or error state rather than an empty dashboard that looks like a valid zero. If the product offers cached data from an earlier session, make that source and its age visible too.
Exercise more than one failure category when behavior differs, such as timeout versus malformed content. A server response that arrives but cannot be parsed may require a different diagnostic from a connection that never completed.
Keep the test deterministic
Use a fake source with a scripted sequence: success, then failure. Avoid dependence on a live endpoint, which can make the test flaky and can change the data under test. If refresh scheduling is involved, trigger the refresh directly or control the scheduler.
A clear assertion should explain which value was retained, which attempt failed, and what status the user saw. This protects both data continuity and the honesty of the dashboard's freshness cues.