Snapshot Testing

A snapshot test records output the first time it runs and compares against that record on every subsequent run. Jest popularised it; every major runner now has one.

It is a genuinely useful technique with a specific and well-documented way of going wrong.

#Where it earns its place

Output that is large, where the correctness criterion is genuinely "unchanged since a human last checked", and where a diff is readable.

// Formatted output: the diff is legible and every change is meaningful.
it('formats an invoice', () => {
  expect(formatInvoice(invoice)).toMatchInlineSnapshot(`
    "Invoice INV-1                        1 January 2026
     ─────────────────────────────────────────────────
     Field Notes                 2 × £12.00     £24.00
     Shipping                                    £3.95
     ─────────────────────────────────────────────────
     Total                                      £27.95"
  `);
});

// Generated SQL: you want to know the moment the query builder changes.
it('builds the orders query with a tenant filter', () => {
  expect(buildOrdersQuery({ tenantId: 't1', status: 'paid' })).toMatchInlineSnapshot(
    `"SELECT * FROM orders WHERE tenant_id = $1 AND status = $2 ORDER BY placed_at DESC"`
  );
});

// C#, Verify — the .NET approval-testing library.
[Fact]
public Task Serializes_an_order_for_the_public_api()
{
    var order = OrderBuilder.Paid(sku: "book-1", quantity: 2);

    return Verify(ApiSerializer.Serialize(order))
        .ScrubMember("Id")              // non-deterministic fields, scrubbed
        .ScrubInlineGuids();
}

#Where it fails

// A 400-line tree. Changes on every styling tweak. Approved without reading.
expect(render(<OrderPage order={order} />).container).toMatchSnapshot();

The mechanism of failure is social:

1. A refactor changes the markup in a way nobody cares about.
2. Forty snapshots fail.
3. Someone runs jest -u.
4. The diff is 4,000 lines; nobody reads it.
5. Repeat monthly.

After six months the snapshots record whatever the code does, which is precisely the thing a test is supposed to be independent of. They still appear in the count, still take time to run, and assert nothing.

#Rules that keep them honest

Inline, not external. toMatchInlineSnapshot puts the expected value in the test file, so a pull request shows the change in context rather than in a .snap file reviewers skip.

Small. If the snapshot does not fit on one screen, the assertion is too broad. Snapshot the thing you care about:

// Instead of the whole tree:
expect(screen.getByRole('table', { name: 'Order lines' }).textContent)
  .toMatchInlineSnapshot(`"Field Notes2£12.00£24.00"`);

Deterministic. Dates, UUIDs, random values and ordering must be pinned or scrubbed, or the snapshot becomes a flaky test.

expect(order).toMatchSnapshot({
  id: expect.any(String),
  createdAt: expect.any(Date)
});

--ci in the pipeline. Without it, a missing snapshot is written and the test passes — so a new test can pass on its first CI run having asserted nothing.

jest --ci          # a missing snapshot fails instead of being written

Fail on obsolete snapshots. An orphaned snapshot is dead weight that also hides the fact that a test was deleted.

// jest.config.js
module.exports = { ci: true };

#Better alternatives, usually

Explicit assertions. Three lines naming the three things that matter, which fail with a message about what was wrong rather than a diff.

Property assertions. toMatchObject checks the fields you care about and ignores the rest, so unrelated additions do not break it.

Contract or schema validation. For API responses, asserting against a JSON Schema or OpenAPI document says what must be true rather than what happened to be true. See contract testing.

Visual regression for anything genuinely visual. A DOM snapshot cannot see that the button is now white on white; a screenshot comparison can:

// Playwright. This is what people usually want when they snapshot markup.
await expect(page).toHaveScreenshot('checkout.png', { maxDiffPixels: 100 });

See screenshots.

#The review test

Before adding a snapshot, ask: when this fails in six months, will anyone read the diff?

If the honest answer is no, it is not a test. Write the three assertions that will actually be read instead.