A communityA timeout says a condition did not complete within a limit. Identify that condition before increasing the limit.
Identify what is waiting
Record the test and last completed action. Determine whether the failure comes from an explicit expectation, a test-wide timeout or pumpAndSettle. Preserve the first failure and stack before rerunning the entire suite.
The API definition of pumpAndSettle concerns scheduled frames. An indeterminate progress animation can keep that condition open. Completion of the helper is not a general guarantee that every external request or application operation succeeded.
Trace an action to an expected state
- Start the smallest test that still times out.
- Name the state immediately before the triggering action.
- Identify what should finish: finite animation, controlled future or state transition.
- Inspect what schedules the next frame and whether it has an endpoint.
- Advance the test deliberately and assert the intended state.
- Compare against the original implementation to check that the regression is distinguished.
Read the API for the SDK under review before changing test mechanics. Avoid replacing every wait in a suite. A precise wait belongs to that test’s behaviour; a broad delay may hide an extra frame introduced by a regression.
Work through a spinner example
In a synthetic search screen, a loading indicator animates until a controlled response arrives. The test taps Search and waits for all frames to settle before completing that response. It is waiting for an animation the test itself keeps alive.
Assert that loading appears, complete the controlled response, advance the required frames, then assert results. Add an explicit error response as a separate case. Do not suppress the timeout or catch the exception and call the test successful.
| Observation | Question |
|---|---|
| Spinner continues | Which operation ends loading? |
| Result exists, assertion fails | Does the finder identify the intended state? |
| Only fails after other tests | Is unfinished work retained? |
Record why the correction is valid
Explain why the original wait could not finish, what event ends the state and what the assertion proves. Keep the failed command and successful rerun separately. A shorter run is useful, but is not evidence of correct behaviour by itself.
If the test depends on an uncontrolled service, create a reproducible setup or mark the dependency unresolved. Do not describe a guessed duration as a measured network requirement. When a real target is necessary, keep its outcome separate from the widget environment.
Retain boundary cases: no results, a failed response and repeated submission can end loading differently. Include only those relevant to the changed behaviour; one green happy-path test should not erase a documented failing state.
Visual procedure
Action starts work; then Identify awaited state; then End controlled loading; then Assert visible outcome. This is an explanatory illustration, not a test result.