Cypress · Browser testing end to end
How do you debug a failing Cypress test?
Short answer
Use the runner's command log and DOM snapshots first, then cy.pause, .debug or the browser DevTools. Add cy.log and intercept assertions to narrow down whether the failure is timing, state or a selector.
The interactive runner is the first debugging tool. It lists every command, shows the DOM snapshot at that step, and displays the assertion error. Hovering a command reveals what the page looked like. From there you can pause execution and inspect the live browser.
it("debugs the cart state", () => {
cy.visit("/cart");
cy.get("[data-cy=add]").click();
cy.get("[data-cy=cart-count]")
.debug()
.should("have.text", "1");
});A debugging sequence
- Read the failing command and its DOM snapshot in the runner
- Use cy.pause to stop the run and step through commands
- Use .debug or a debugger statement to inspect a subject
- Check the Network tab or cy.intercept to see whether the expected request happened
- Add cy.log for values that are not visible in the DOM
- Reproduce in open mode before changing the test
Distinguish a timing failure from a logic failure. If the element appears a moment later, an intercept or a retrying assertion is the fix. If the element never appears, inspect the request, the route and the application state. Re-running until it passes hides which of those happened.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What does the DOM snapshot in the runner show?
- 2How do you inspect a command subject in DevTools?
- 3How do you tell a timing failure from a logic failure?
- 4Why should pause and debugger not be committed?
Say it in the interview
I start with the runner's command log and DOM snapshots, because they show exactly which command failed and what the page looked like. Then I pause with cy.pause or inspect a subject with .debug in DevTools. I check the network and add logs to separate timing from logic. I remove pause and debugger statements before committing.
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.