Snapshot Testing Tradeoffs

The plain-language idea

A snapshot test renders a component, serializes the output (usually the rendered markup), and saves it to a file. On every later run, the test re-renders the component and diffs the new output against the saved file. Any difference — intentional or not — fails the test.

That's the whole mechanism, and it's genuinely useful for one specific job: catching unintended changes to output you didn't mean to touch. It's a poor substitute for testing behavior — whether a button actually does the right thing when clicked — which is what the testing lesson's interaction-based approach is for. Snapshot testing checks shape; behavioral testing checks what happens.

See it in a real thing: a snapshot test and its failure mode

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

function UserCard({ name, role }) {
  return (
    <div className="card">
      <h2>{name}</h2>
      <p>{role}</p>
    </div>
  );
}

test("renders a user card", () => {
  const { asFragment } = render(<UserCard name="Adesh" role="Frontend Engineer" />);
  expect(asFragment()).toMatchSnapshot();
});

The first run writes a .snap file:

exports[`renders a user card 1`] = `
<div class="card">
  <h2>Adesh</h2>
  <p>Frontend Engineer</p>
</div>
`;

Now someone renames the class from card to user-card as part of an unrelated CSS cleanup. The test fails — correctly, something did change. But here's the failure mode: the fastest way to make a red test suite green is jest --updateSnapshot, which overwrites the saved file with whatever the component renders right now, no matter whether that's correct. Run that command without reading the diff, and you've just approved every accidental change alongside the intentional one — the test suite is green and tells you nothing.

What people usually miss

Watch out

• A passing snapshot test proves stability, not correctness. The very first snapshot is trusted blindly — if the component was already wrong when you wrote the test, the snapshot just locks in the wrong output forever, and every future run "passes" against a broken baseline.
• --updateSnapshot is a batch accept-all, not a review tool. It regenerates every failing snapshot in one pass with no per-change confirmation — the diff you should have read is exactly the thing this command lets you skip.
• Full-page or full-component snapshots rot fast. Any prop, any child, any bit of unrelated markup nearby changes the whole serialized blob, so unrelated PRs collide on the same snapshot file constantly — this is the concrete reason many teams restrict snapshots to small, stable subtrees instead of whole pages.
• A snapshot test can't tell you why something changed, only that it did. It has no concept of "this was intentional" versus "this was a bug" — that judgment call is entirely on whoever reviews the diff, which only works if someone actually reads it.

The genealogy: the same suite, a different question

The testing lesson covers rendering a component and asserting on behavior — clicking, typing, checking what the user would actually see happen. Snapshot testing answers a narrower, mechanical question on top of that: "did the output change at all since last time," which is worth asking for some things and worth skipping for most interactive behavior, where a behavioral assertion says what you actually mean far more precisely.