Flaky Page
Practice tests that survive random failures, random delays and elements that are re-created while you work.
1. Unreliable Request
Challenge Tasks (1)
Tick a task when your script passes it. Tasks with a pass/fail box tick themselves.
2. Random Delay
Challenge Tasks (1)
Tick a task when your script passes it. Tasks with a pass/fail box tick themselves.
3. Re-rendered List
Challenge Tasks (1)
Tick a task when your script passes it. Tasks with a pass/fail box tick themselves.
4. Async Counter
Challenge Tasks (1)
Tick a task when your script passes it. Tasks with a pass/fail box tick themselves.
5. Solutions
Try the challenges yourself first. Reference solutions are hidden until you ask for them.
About this Flaky Page page
A flaky test passes and fails on the same code. Causes include fixed sleeps, race conditions, shared state and elements re-rendered mid-test. This page injects random failures, delays and DOM re-renders so you can reproduce them. Fix them with condition-based waits, fresh locators, web-first assertions and bounded retries instead of longer sleeps.
Frequently asked questions
What is a flaky test?
A flaky test gives different results on repeated runs without any change to the code or the test. Typical causes are timing, shared test data, network variance and unstable locators. The result cannot be trusted either way, so it should be fixed or quarantined.
How do I fix a StaleElementReferenceException?
The element was removed or re-rendered after you found it. Locate it again right before use, or wait with an expected condition that re-finds it, such as element_to_be_clickable. In Playwright, locators are lazy and re-resolve on each action, so this rarely occurs.
Should I use retries to deal with flaky tests?
Retries keep a pipeline moving but hide the cause. Playwright supports retries in config and Cypress has test retries since version 5. Use them as a stopgap, track tests that needed a retry, and fix the underlying wait or locator.
Why do tests pass locally but fail in CI?
CI machines are usually slower, run in parallel and have less memory, so timing assumptions break. Replace sleeps with condition waits, avoid shared data between tests, and add traces or videos on failure to see what the page looked like.
How can I find the cause of a flaky test?
Run it many times, for example Playwright's --repeat-each, and compare failing traces to passing ones. Look for an action that ran before the page was ready, or an element replaced between find and click. Fix the timing at that step.
Free developer tools on Randomly.online
QA Playground is part of Randomly.online. These tools help while you write and debug tests: