Cypress · Browser testing end to end
How do you diagnose and fix flaky Cypress tests?
Short answer
Find the shared or timing-dependent state behind the flake. Replace arbitrary waits with intercepts or retrying assertions, isolate data per test, and remove order dependence rather than retrying the test.
A flaky test passes and fails without a code change. That usually means the test depends on something it does not control: a request that may or may not finish, data left by another test, an animation, or a selector that matches more than one element. The fix is to make the dependency explicit.
Common root causes
- Fixed waits that are too short on slow machines
- Requests that race with the assertion
- Shared database records created by another test
- Selectors that match multiple elements and depend on order
- Animations or transitions that intercept a click
- Time, locale or random data that differs between runs
- Order dependence hidden by a single passing run
beforeEach(() => {
cy.intercept("GET", "/api/orders").as("getOrders");
cy.visit("/orders");
cy.wait("@getOrders");
});
it("shows the empty state", () => {
cy.intercept("GET", "/api/orders", []);
cy.reload();
cy.get("[data-cy=empty]").should("be.visible");
});Reproduce the failure before changing anything. Run the spec repeatedly, run it alone and with the full suite, and check whether the failure follows a specific test. Cypress can retry tests in run mode, but retries are a signal, not a cure. A test that only passes on the second attempt is still broken.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you tell whether a flake is caused by shared data?
- 2Why are test retries not a fix?
- 3How do you handle animation-related flakes?
- 4What is the role of test isolation in flakiness?
Say it in the interview
I treat flakiness as an uncontrolled dependency. I reproduce it by running the spec alone and in the full suite, then look for races, shared data, ambiguous selectors or time-dependent values. I replace fixed waits with intercepts or retrying assertions and isolate data per test. Test retries can tell me a test is flaky, but I do not use them as the fix.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Cypress mock interview and get scored feedback on depth, clarity and confidence.