🐞 Debugging & Selector Playground

Debugging & Selector Playground: Cypress's debugging advantage comes from this: since it automatically snapshots the DOM after every command, when a test fails you already have a

Cypress's debugging advantage comes from this: since it automatically snapshots the DOM after every command, when a test fails you already have a full black-box recording — like the flight data recorder on an aircraft: after an incident, the last 30 minutes of audio and telemetry are right there without any extra recording step. But if the black box is already there, why do you need cy.pause() and cy.debug()? Because a black box is read after the crash; during live development you want to see where the test is heading before it fails — cy.pause() freezes the test at exactly that moment and lets you explore the DOM freely. cy.debug() pushes the current DOM element directly into the DevTools console where you can query it with jQuery methods. In Java, this is like setting a breakpoint in the Eclipse or IntelliJ debugger and inspecting variables in the Watches panel. The Selector Playground solves the real QA business problem: should you use XPath, CSS, or data-cy to find an element? The Playground recommends options in order of fragility, immediately verifies whether it produces a single unique match, and prevents "element not found" failures before they ever reach CI.

Cypress's biggest debugging advantage is that it automatically snapshots the DOM after every command — so most of the time, WITHOUT writing extra log/debug code, you can just click a past step in the Command Log (time-travel) to see what went wrong. When extra tools are needed, cy.debug(), cy.pause(), and the Selector Playground come into play.

cy.debug() and cy.pause()

Micro Lab: Cypress — cy.get() selection

Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.

A breakpoint inside .then() with debugger

Step by Step: Cypress — cy.get() selection

Check if data-cy attribute exists — if yes, use cy.get("[data-cy=btn]")

If no data-cy, write cy.get("#id") or cy.get(".class")

If text content matters, use cy.contains("Login") or chain .contains()

If nested structure needed, find child element with .find("button")

Assert: .should("be.visible"), .should("have.text", "...")

What is the Cypress element selection and chaining order?

In Java, debugging requires STOPPING the code (a breakpoint) or adding extra println lines. In Cypress, since the test already leaves a "snapshot" at every step, most debugging happens by clicking backward in the Command Log without writing extra code — this "time-travel debugging" doesn't exist in the Selenium/Java world.