skip to content

How far should a team trust a Cypress snapshot as evidence of what the user saw?

level: principalimportance: should knowfreq 34%

answer

  1. Ask what claim it can support
  2. Structure yes, appearance conditionally
  3. Runtime state is not evidence
  4. Triage must survive an unattended run
  5. Assertions carry it, snapshots explain it

basics

~20 s

Trust a Cypress snapshot completely for structure — markup, attributes, text, the URL — and not at all for appearance or behaviour. Draw that line explicitly, because a team treating it as a picture reads the wrong conclusions and cannot use it in CI.

solid answer

~50 s

A Cypress snapshot is a cloned DOM, so it is authoritative about **what was in the document** and silent about everything that only exists while something is running. My line is: a snapshot settles "was the element there, with what text, classes and attributes, at what URL", and it never settles "did it look right", "did the chart draw correctly" or "did the embedded widget load". I would write that distinction down, because two failure modes follow from getting it wrong: engineers reading a placeholder frame or a blank canvas as an application defect, and triage runbooks that assume a snapshot exists when a headless run never captured one. The team convention I would set is that assertions carry the evidence and snapshots explain it — so the investigation still works on a machine nobody is sitting in front of.

go deeper

for a junior

Check anything surprising in a restored snapshot against the live application before you call it a defect; some gaps are the mechanism, not the app.

for a middle

Be able to say precisely which claims the artefact supports — structure and content yes, appearance conditionally, runtime state never — and why each falls where it does.

for a senior

Demonstrate the judgement in practice: an investigation you led that stayed diagnosable because the assertions carried the evidence rather than the artefact.

for a principal

Own the written convention and the trade-off behind it, including the memory cost of retention and the component-level contract that makes visual state inspectable.

## The question behind the question "How much do you trust it" is really "what claims will you let this artefact support in a code review, a bug report or an incident write-up". A Cypress snapshot is unusually good evidence for some claims and actively misleading for others, and the difference is not obvious from looking at one — a restored snapshot of a support-ticket queue looks like the page. That is what makes an explicit team line worth having. ## Where the line falls The capture is a deep clone of `<body>` with the executable and styling tags removed, plus the `<html>` attributes, the URL and a separately collected list of stylesheets. Everything that is markup is faithful; everything that is runtime is not. - **Trustworthy:** which elements existed, their nesting, their text, their classes and attributes, form field values and checked state, and the URL the app was on. - **Conditionally trustworthy:** appearance. Styling is faithful only to the extent the stylesheets could be read; anything captured by reference is refetched when you look, which makes an old snapshot's look depend on infrastructure nobody controls. - **Not evidence at all:** anything inside a frame, anything drawn onto a canvas, animation or timer state, event handlers, and anything that happened *between* two commands. ## Three decisions worth making deliberately 1. **What counts as proof in a bug report.** Structure claims backed by a snapshot are fine. An appearance claim needs a different instrument, and pixel comparison is its own discipline with its own tooling rather than something to improvise on top of time travel. 2. **Whether triage may depend on it.** A runbook step that says "pin the failing command and inspect the DOM" quietly only works on a developer's machine, because an unattended run captures no snapshots at all. If your on-call path for a flaky ticket queue routes through time travel, it has a hole in it. 3. **What the application must expose so debugging does not depend on visuals.** If a queue chart's numbers only exist inside a canvas, no snapshot will ever show them. Putting the same values on the host element as data attributes costs almost nothing and turns an uninspectable visual into inspectable markup. ## The costs on the other side Arguing for more retention has a real price, and a lead should name it rather than hand-wave it: | Choice | What it buys | What it costs | |---|---|---| | Keep the open-mode default retention | Time travel across a long local session | Browser memory grows with the session | | Lower the retained-test count | A lighter, more responsive open-mode session | Older commands stop restoring sooner | | Lean on assertions instead of snapshots | Diagnosis that survives an unattended run | More deliberate test authoring up front | | Expose state as data attributes | Visuals become inspectable structure | A small, permanent contract in the component | ## A convention that holds up The rule I would put in a team's testing guide is short: **assertions carry the evidence; snapshots explain it.** A failing test should say what it expected and what it found, in a message a reader can act on without opening anything. The snapshot is then a convenience for the person sitting in front of the app — the fastest way to understand *why* the assertion read what it read — rather than the thing the diagnosis depends on. Two habits follow from that: - **Write assertions that fail informatively.** A chain that checks the row count, then the row's state, then the banner tells you where it broke without any artefact at all. - **Treat a restored snapshot as a starting point, not a verdict.** A grey placeholder box or a blank chart is the mechanism showing its limits, not the application misbehaving; confirm anything surprising against the live app before it becomes a bug report. ## Where reasonable people differ There is a genuine argument for the opposite emphasis on a small team working entirely locally on a UI-heavy product: time travel is fast, free and immediate, and demanding that every diagnosis survive an unattended run is overhead nobody is paying for yet. That position is defensible right up to the first failure that only reproduces in CI. The judgement is about when your suite crosses that line — and the honest answer is that most suites cross it earlier than the team notices, which is why writing the convention down before the first CI-only flake is cheaper than discovering it during one.

  • What would you change in a team's testing guide after this discussion?
    Two lines. First, that a Cypress snapshot supports structural claims only, so a placeholder frame or an empty canvas is never reported as a defect without checking the live app. Second, that no triage step may assume a snapshot exists, because an unattended run captures none.
  • How do you push back when someone asks to raise snapshot retention to debug a long suite?
    Ask which mode they mean. In a run there is nothing to raise — the setting is pinned. In open mode it is a real trade against browser memory over a long session, and it is usually cheaper to shorten the spec you are debugging than to retain more of a suite you are not looking at.

saying these in an interview costs you the question

  • Treats a snapshot as a picture of the page
  • Files a bug from a placeholder frame or blank canvas
  • Builds a CI triage runbook around time travel
  • Argues appearance checks belong in time travel
  • Ignores the memory cost of retaining more snapshots