Test what users see during failure and recovery, not just whether a request returns an error.
Build fixtures with a purpose
A successful quote is only one input your application must handle. Create a small local fixture set: a valid observation, an old observation, an empty history, malformed data, denied access, and a temporary service failure. Give each fixture an expected visible result.
Use clearly labeled synthetic prices and disposable test credentials. Keep these checks local or in a dedicated test environment so they do not depend on current market activity or consume a customer’s allowance. Control the test clock when checking data age; a fixture should not become stale accidentally as the calendar advances.
Exercise slow and canceled requests
Delay a response beyond the client’s request budget. Confirm that loading ends and the interface offers a useful recovery state. Then navigate away while a request is pending and verify that its eventual result does not overwrite the next screen.
For browser code using AbortSignal.timeout(), MDN documents that the delay is measured in active time and may pause when a document is suspended. A timeout produces a TimeoutError. Treat this as a client-side cancellation mechanism, not proof that the server stopped processing or that the request was never metered. [1]
Check the value left on screen
After one successful quote, make the next request fail. Does the interface preserve the last observation with its original timestamp? Does it clearly mark an old value? A zero price, an endless spinner, or a fresh-looking timestamp attached to an old quote can all mislead users.
Next, return two successful responses in reverse order. The older observation should not displace the newer one merely because it arrived last. Include a symbol change while a fetch is pending to catch responses that belong to a previous selection.
Verify recovery has a stopping point
Simulate a sequence of failures followed by success. Check that retries stay within their configured attempt and time budgets, and that recovery restores the normal polling schedule without leaving duplicate loops running. Authentication failures should lead to an access state rather than endless retries.
Finally, inspect the diagnostics produced by each case. Endpoint patterns, response status, and request duration can help explain a failure without exposing an API key. Keep test assertions focused on observable behavior: accurate labels, bounded requests, and a usable screen after recovery.
References
Primary sources for the technical details in this article. Implementation suggestions are our own.