Waits in the real world
The timing problems behind most flaky tests. In each one, the fix is to wait for the right condition, because a fixed sleep will be too short on a bad day.
Refresh the dashboard, then export it.
Nothing exported yet
The overlay covers Export for 3 seconds. Export is visible and enabled the whole time, so clicking it too early fails with "element click intercepted".
Reserve the keyboard. This list redraws itself every 2 seconds.
Redrawn 0 times
Nothing reserved yet
Every redraw replaces the buttons with new ones, with the same IDs. An element you found before a redraw is stale: find it again just before you use it.
Open Order 37. It doesn't exist until you scroll far enough to load it.
Loading more...
End of the list
Loaded 10 of 50
No order opened
Scrolling to the bottom of the box loads 10 more after a moment. Scroll, wait for the list to grow, and repeat.
Load the orders. The server takes about a second and a half to answer.
Not loaded yet
A real request to /api/practice/orders. The server always returns orders, so reaching "No orders yet" takes a mocked empty response.
Load the report. The first request fails with a 500, so your test has to notice the error and retry.
Not loaded yet
An error is an answer too: wait for either the data or the error, or your test sits there until it times out.