HTML Academy · Lesson

HTML Snapshot Testing

Catch unintended HTML changes with snapshot tests.

HTML Snapshot Testing is a free HTML Academy lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the HTML Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What Snapshot Testing Is

Snapshot testing records the rendered output of a component or page on first run, then on subsequent runs compares the new output to the saved snapshot. Any change in HTML output causes the test to fail until the snapshot is intentionally updated.

Jest Snapshot Testing

Jest's toMatchSnapshot() matcher serializes a value (including JSX rendered to HTML) and compares to a saved file. npx jest -u updates snapshots when intentional changes happen. Tests serve as a regression net for accidental rendering changes.

import { render } from "@testing-library/react";
import Button from "./Button";

test("Button renders consistently", () => {
  const { container } = render(<Button>Save</Button>);
  expect(container.innerHTML).toMatchSnapshot();
});

Storybook Test Runner

Storybook Test Runner runs every story and snapshots its output via axe (accessibility) and DOM serialization. Combined with Chromatic, it adds visual regression on top — pixel-level diffs in addition to DOM diffs.

Visual Regression with Percy or Chromatic

Percy and Chromatic snapshot rendered pages as images and surface visual diffs. They catch CSS regressions that DOM snapshots miss (a font swap, a margin tweak, a colour shift). Pair DOM snapshots (cheap, fast) with visual snapshots (expensive, comprehensive).

Snapshot Maintenance

Snapshots that change "too easily" become noise. Avoid snapshotting unstable values (dates, ids, random keys). Use Jest's property matchers (expect.any(String)) for fields that vary legitimately between runs. Keep snapshots small and focused.

Code Review for Snapshots

Snapshot file diffs in pull requests are first-class review material. Reviewers verify that DOM changes are intentional and welcome — catching accidental cascading effects from a "simple" CSS change. Treat snapshot diffs like any other diff.

Don't Snapshot Everything

Snapshot huge top-level page renderings is fragile — every minor change cascades into a giant diff. Snapshot at the component level: each Button, each Card, each FormField. Page-level rendering deserves visual regression tests instead.

Snapshot Serialization

Choose how to serialize: full HTML, simplified DOM, props-only, accessibility tree. Each format catches different regressions. For UI components, full HTML is the most thorough; for prop-driven logic, props-only is cheaper and rarely false-positives.

When Snapshots Break

The most common cause is a refactor that produces equivalent but differently-structured HTML. Inspect the diff: if the change is intentional and good, update the snapshot. If unexpected, fix the underlying code. Never blindly run jest -u without inspection.

Cross-Browser Snapshots

Visual regression tools render in multiple browsers and report browser-specific differences. Use this to catch CSS that renders differently in Safari vs Chrome — common for new layout features in early-adoption phase. Without cross-browser snapshots, such regressions are caught only by manual QA.

Combining With Other Tests

Snapshot tests are necessary but not sufficient. They catch unintentional rendering changes but not logic bugs (clicking the button does the right thing). Pair with unit tests for behavior and end-to-end tests for user flows — each layer catches different failures.

Performance

Snapshot tests are fast — they compare strings/files. Visual regression tests are slower (render pixels, compare images, often across browsers). Run snapshots on every CI build; run visual regression on every PR but possibly not every commit, depending on CI budget.

Knowledge Check

Why are DOM snapshot tests usually complemented by visual regression tests like Percy or Chromatic?

Summary

Snapshot testing captures rendered HTML on first run and flags any change on subsequent runs. Use Jest toMatchSnapshot for component DOM, Storybook Test Runner for stories, Percy/Chromatic for visual regression at the pixel level. Snapshot at the component level (not page-level), exclude unstable values, review diffs carefully in PRs. Combine with unit and end-to-end tests for full coverage.

Frequently asked questions

Is the “HTML Snapshot Testing” lesson free?

Yes — the full text of “HTML Snapshot Testing” is free to read here on the web, and the HTML Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the HTML Academy course, upgrade to CoddyKit PRO.

What will I learn in “HTML Snapshot Testing”?

Catch unintended HTML changes with snapshot tests. You practise HTML Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start HTML Academy?

No prior experience is required. HTML Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “HTML Snapshot Testing” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this HTML Academy lesson?

Yes. Every HTML Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to HTML Academy