Snapshot Testing

What it is

A snapshot test renders a value once, saves it as a golden file, and on every later run compares the new output against the stored snapshot. If they differ, the test fails and you either accept the change (updating the snapshot) or fix the bug.

Snapshots are ideal when the output is verbose or structural and writing an explicit assertion by hand would be tedious: serialised objects, rendered HTML, CLI help text.

1
   first run                     later runs
2
   ─────────                     ──────────
3
   render output                 render output
4
        │                             │
5
        ▼                             ▼
6
   write __snapshots__          compare to stored
7
        .snap file                    │
8
                                      ├── equal   → pass
9
                                      └── differ  → fail → review → update?

Inline snapshots store the expected value next to the test, so the expectation is reviewed like normal code instead of hidden in a .snap file.

When to use it / when to avoid it

Use it for

Large structural output: serialised config, ASTs, CLI --help, error messages
Rendered HTML or component trees where a full-tree diff is useful
Detecting unintended change in stable, human-reviewed artefacts
Bootstrapping tests for legacy output you cannot yet assert precisely

Avoid it when

The value is small — write an explicit expect(x).toBe(...) instead
The output is inherently unstable (timestamps, random ids, absolute paths)
The snapshot is accepted blindly on every failure — it then tests nothing
It becomes a huge opaque blob no reviewer reads

Frameworks & tools

Tool	Ecosystem	Notes
Vitest snapshots	JS/TS	`toMatchSnapshot`, `toMatchInlineSnapshot`, `-u` to update
Jest snapshots	JS/TS	The original; same API as Vitest
insta	Rust	`assert_snapshot!`/`assert_debug_snapshot!`, `cargo insta review`
Insta / ApprovalTests	.NET	`Verify` library for approval-style snapshots
ApprovalTests	Multi	Golden-master / approval testing across languages
Pytest-regressions	Python	`data_regression`, `file_regression` fixtures
syrupy	Python	Snapshot plugin for pytest
Playwright snapshots	JS/TS	`toMatchSnapshot` for DOM and ARIA trees

Quick setup

1
npm install -D vitest
2
npx vitest run           # writes missing snapshots
3
npx vitest run -u        # update changed snapshots

1
pip install syrupy pytest
2
pytest --snapshot-update

1
go get github.com/gkampitakis/go-snaps
2
# snapshots live in __snapshots__; update with -update
3
go test ./... -update

1
<dependency>
2
  <groupId>com.approvaltests</groupId>
3
  <artifactId>approvaltests</artifactId>
4
  <version>25.1.0</version>
5
  <scope>test</scope>
6
</dependency>

1
dotnet add package Verify.Xunit

Example

1
import { describe, it, expect } from 'vitest';
2
import { renderInvoice } from './invoice';
3

4
describe('renderInvoice', () => {
5
  it('renders a standard invoice', () => {
6
    expect(renderInvoice(sampleOrder)).toMatchSnapshot();
7
  });
8

9
  it('formats totals inline', () => {
10
    expect(formatTotal(1234.5)).toMatchInlineSnapshot('"$1,234.50"');
11
  });
12
});

1
from invoice import render_invoice
2

3
def test_renders_invoice(snapshot):
4
    assert render_invoice(sample_order) == snapshot

1
import (
2
  "testing"
3

4
  "github.com/gkampitakis/go-snaps/snaps"
5
)
6

7
func TestRenderInvoice(t *testing.T) {
8
  snaps.MatchSnapshot(t, RenderInvoice(sampleOrder))
9
}

1
import org.approvaltests.Approvals;
2
import org.junit.jupiter.api.Test;
3

4
class InvoiceTest {
5
  @Test
6
  void rendersInvoice() {
7
    Approvals.verify(Invoice.render(sampleOrder));
8
  }
9
}

1
using VerifyXunit;
2
using Xunit;
3

4
[UsesVerify]
5
public class InvoiceTests
6
{
7
    [Fact]
8
    public Task RendersInvoice() =>
9
        Verifier.Verify(Invoice.Render(SampleOrder));
10
}

Anti-patterns & best practices

Review every snapshot change in the diff. A snapshot is only as good as the human who reads it; blind -u turns the test into decoration.
Keep snapshots small and scoped. Snapshot one meaningful artefact, not a whole page with incidental markup.
Make output deterministic. Freeze time, seed randomness, and normalise paths and ids before snapshotting.
Prefer inline snapshots for small values. Keeping the expected value in the test makes it reviewable and self-documenting.
Commit snapshots to version control. They are test data; if they are gitignored they will churn and hide regressions.
Do not snapshot what an assertion says better. expect(x).toBe(42) beats a .snap file containing 42.