In the Cypress Command Log, what do hovering and clicking a command do?
answer
- The left pane remembers each step
- Two gestures, two different durations
- One previews, the other locks it
- The row number becomes a pin icon
- Pinning also prints to the console
basics
~20 sHovering a Cypress Command Log entry restores the app under test to the DOM snapshot taken when that command ran. Clicking pins that snapshot so it stays put, and prints the entry's console properties to the browser console.
solid answer
~50 sThe Command Log is the left pane of the Cypress app in open mode: every command and hook of each test, in order, one row per step. Cypress captures a DOM snapshot around each of those commands, and the log is how you read them back. **Hovering** a row temporarily restores the application under test to that snapshot — the DOM, the URL and the viewport as they were then. If the command yielded an element, Cypress highlights it and scrolls it into view. Move away and the live page returns. **Clicking** a row pins it: the row number becomes a pin icon, hovering other rows no longer changes the preview, and the entry's console properties are printed to the browser's developer-tools console. Click again to unpin. Neither gesture works while the spec is still running.
code
javascript · 13 linesdescribe('support ticket queue', () => {
beforeEach(() => {
cy.intercept('GET', '/api/tickets?status=open').as('openTickets')
cy.visit('/queue')
cy.wait('@openTickets')
})
it('escalates the oldest unassigned ticket', () => {
cy.get('[data-testid="ticket-row"]').first().as('oldest')
cy.get('@oldest').find('[data-testid="escalate"]').click()
cy.get('@oldest').should('have.attr', 'data-priority', 'urgent')
})
})go deeper
Be ready to name both gestures and what each one lasts for: hover previews a step, click pins it. Knowing that the preview is a captured snapshot, not a re-run, is the point of the question.
Explain what a restore actually puts back — DOM, URL, viewport, element highlight — and why the runner debounces hover instead of restoring on every mouse move.
Show how you drive a real diagnosis from a pin: which entry you pin first, what you read out of its console output, and how the hitbox on an action command tells you whether a click landed where you meant it to.
Be ready to say where this surface stops being enough for your team, and what a failure that nobody can reproduce locally needs to carry instead.
## The Command Log, and why it can time travel In `cypress open`, the Cypress app splits into two panes. The left pane is the **Command Log**: an ordered list of every command and every hook that ran in the spec, one row per step, grouped under the test it belongs to and, where relevant, under its `before`, `beforeEach`, `afterEach` or `after` hook section. The right pane renders the **application under test** — the page `cy.visit()` loaded. Cypress captures a snapshot of the DOM around each logged command as the test goes, and the Command Log is the surface those snapshots are read back through. That is what makes the log interactive rather than a transcript: **each row is a moment in the run you can return to.** Rows come in two flavours, and only one of them is a command: - **Numbered rows** are commands — `cy.visit()`, `cy.get()`, `.click()`, `.should()` and so on. - **Grey, unnumbered rows** are page events Cypress noticed on its own: network XHR and fetch requests, URL hash changes, page loads, and form submissions. ## Hover: a temporary preview Move the pointer onto a row and Cypress swaps the application-under-test frame from the page's current state to the snapshot belonging to that command. Concretely, hovering restores: - the **DOM** — the snapshot's `body` and the attributes that were on `<html>` at the time; - the **URL** shown above the preview, as it was when the snapshot was taken; - the **viewport dimensions** recorded with the snapshot, so a step taken after `cy.viewport()` previews at that size; - a **highlight** on the element the command yielded, scrolled into view, for a `cy.get()` or a `cy.contains()`; - a **red hitbox** at the coordinates an action command dispatched its event at. Move the pointer off the row and the live page comes back. The reporter deliberately waits about 50 ms of continuous hover before it asks for a snapshot, and about the same after you leave before it restores the live page. Sweeping the mouse down a two-hundred-row log therefore costs nothing — no row is hovered long enough to trigger a restore, and the runner never thrashes. ## Click: a pin that stays Hovering is for scanning. **Pinning is what you actually debug from.** Clicking a row does four things at once: 1. The row's number is replaced by a pin icon and the row is marked as pinned. 2. The preview stays on that snapshot. Hovering other rows no longer changes it, so you are free to move the mouse into the preview and poke around the restored DOM. 3. The command's **console properties** are printed to the browser's developer-tools console — for a `cy.get()` that is the `Selector` it used, the number of `Elements` it matched, and the value it `Yielded`. The row flashes *"Printed output to your console"* so you know it happened. 4. A small toolbar appears over the preview carrying a **Highlights** toggle and an unpin button. Clicking the pinned row again, or the unpin button, releases the pin and puts the live page back. ## Hover versus click at a glance | | Hover | Click | |---|---|---| | How long it lasts | while the pointer stays on the row | until you unpin | | Console output | none | the entry's console properties are printed | | Other rows | each one you hover replaces the preview | ignored while a pin is held | | Interacting with the preview | impractical — leaving the row ends it | intended: the state is held for you | | Element highlight | drawn automatically | drawn, and toggleable | ## When neither gesture does anything Time travel is not always available, and the app tells you which case you are in: - **While the spec is still running.** Pinning is disabled outright, and hovering reports *"Cannot show snapshot while tests are running"* — the page is still moving underneath you, so restoring an old state would fight the run. - **When the row has no snapshot.** Some entries never carry one; the preview stays on the live page and the app notes that the snapshot is missing. - **When the test has aged out of memory.** Cypress retains snapshots only for the most recent tests, so rows far back in a very long session can list fine yet no longer restore. ## Using it on a support-ticket queue Suppose a spec that escalates the oldest unassigned ticket fails intermittently, and you have reproduced it locally. The log gives you an ordered account of what the runner did, and pinning gives you the page as it was at each step. Pin the `cy.get()` that found the ticket rows and read the `Elements` count in the console: if it says `0`, the queue had not rendered yet and the failure is a waiting problem. If it says `12`, pin the `.click()` on the escalate button instead and look at the restored row — the hitbox shows exactly where the click landed, which tells you whether it hit the button or an overlay that was covering it. Neither answer required re-running the spec, and neither required a `console.log()` added to the test.
- You pinned a Cypress Command Log entry and now hovering other rows changes nothing. Why?A pin holds the preview deliberately. Cypress ignores hover previews while a snapshot is pinned so you can move the pointer off the log and into the restored page without losing the state you were inspecting. Click the pinned row again, or the unpin button on the toolbar over the preview, to release it and get hover previews back.
- Do commands that ran in a beforeEach hook show up in the Cypress Command Log?Yes. Expanding a test in the Command Log shows its own commands plus the commands contributed by the `before`, `beforeEach`, `afterEach` and `after` hooks that ran around it, each under its own hook heading. Those rows hover and pin exactly like the ones from the test body, which is how you check whether setup left the page in the state the test assumed.
Think of it as a scrubber over a recording of your test: hovering scrubs to the frame under the pointer, and clicking parks the playhead there so you can walk around inside that frame.
saying these in an interview costs you the question
- Says Cypress re-runs the command to rebuild the page
- Thinks hovering permanently changes the application's state
- Believes clicking a row re-executes that step
- Expects hover and pin to work mid-run
- Confuses the Command Log with the browser's console output