In a Jest or Vitest component test, expect(container).toMatchSnapshot() passes the very first time it runs. Why does it always pass on that first run, and what risk does that create?

## What a snapshot assertion actually is A snapshot assertion serializes some value — most often a rendered DOM subtree, sometimes a plain object — into text, and compares that text against a previously stored copy. The stored copy is called the snapshot, or baseline. In Jest and Vitest, `expect(value).toMatchSnapshot()` writes to a companion file under `__snapshots__/`, and `expect(value).toMatchInlineSnapshot()` writes the expected text back into the test file itself. The key point is what the runner is comparing. It has no model of what your component *should* render. It only knows what it rendered last time. ## Why the first run passes The first run finds no baseline. Rather than failing, the runner takes the current serialized output, stores it, and reports the assertion as passing. This is deliberate: it is what makes snapshots cheap to add. You write one line, run the suite, and a baseline appears. ```javascript // Run 1: no stored snapshot -> record output, pass // Run 2..n: serialize again, diff against the stored text, fail on any difference expect(container).toMatchSnapshot(); ``` So the very first execution is a *write*, not a *check*. Every execution after it is a check — but a check against a value that a machine chose, not one a human specified. ## The risk this creates If the component was broken when the snapshot was recorded, the snapshot enshrines the broken output. The test is now green forever, and worse, it will go **red** when someone fixes the bug. Reviewers who skim past a `.snap` file — it is large, auto-generated, and looks like noise — approve the bug into the baseline. Compare that with an explicit assertion: ```javascript expect(screen.getByRole('heading', { name: 'Invoice #1042' })).toBeInTheDocument(); ``` Here a human wrote down what "correct" means. If the component renders `Invoice #undefined`, this fails immediately, on the first run, before anything is committed. That is the difference between a specification and a recording. ## Working with the first-run behaviour instead of against it Four habits make snapshots safe to use: 1. **Review the snapshot as source.** A new or changed `.snap` hunk is a claim about output. If you cannot tell from the diff whether it is right, the snapshot is too big. 2. **Keep the captured value small.** Snapshotting an entire page produces hundreds of lines nobody reads; snapshotting one small subtree — or a plain data object derived from the UI — produces a diff a reviewer can judge. 3. **Fail on missing snapshots in CI.** Most runners support this: Jest's `--ci` flag makes a missing snapshot fail the run instead of writing one, and Vitest refuses to create new snapshots when it detects a CI environment. Without it, a snapshot file that was never committed is silently regenerated on the build machine and every test passes. 4. **Pair it with at least one explicit assertion.** Even one `getByRole` check anchors the test to intent, so a reviewer reading the test knows what it is supposed to prove. ## When a recording is the right tool anyway The first-run write is not always a defect. If the value is something you would never hand-write — a formatted string, a generated stylesheet, a serialized error message catalogue, a normalized data structure — recording it and then guarding it against unintended change is genuinely useful. The rule of thumb: a snapshot is appropriate when *any* change to the value deserves human attention, and inappropriate when the value churns for reasons unrelated to the behaviour under test. ## What to say in an interview Say plainly that snapshots assert *sameness*, not *correctness*; that the first run records rather than checks; and that the safeguard is review discipline plus a small captured value, not the tool. Candidates who claim a green snapshot proves the component works have missed the whole mechanism.