Snapshot Testing: A Trap for Developers

The Allure of Snapshot Testing

Look, I get it. Snapshot testing sounds like a dream. You write a test, run it once, and suddenly you have a golden master of your UI or data structure. Any future change that deviates from this snapshot is flagged as a failure. It feels efficient, like a shortcut to comprehensive testing. Who wouldn’t want that?

This is especially true in front-end development where UI changes are frequent. A snapshot test for a component might look something like this:

1
import React from 'react';
2
import MyComponent from './MyComponent';
3
import renderer from 'react-test-renderer';
4

5
it('renders correctly', () => {
6
  const tree = renderer
7
    .create(<MyComponent name="Test User" />)
8
    .toJSON();
9
  expect(tree).toMatchSnapshot();
10
});

When you first run this, Jest creates a __snapshots__ file with the serialized output of MyComponent. The next time you run the test, if the output differs, the test fails. Simple, right? “Just update the snapshot,” you tell yourself. “It was an intentional change.”

The Slippery Slope

Here’s where the trap snaps shut. That “just update the snapshot” mentality is the beginning of the end for robust testing. Over time, developers become desensitized to snapshot failures. The intention was to catch unintended regressions, but it morphs into a tedious chore that often masks real bugs.

Think about it. What happens when a developer accidentally introduces a bug that changes the UI slightly? The snapshot test fails. Great! But what if that developer, under pressure or simply out of habit, clicks “update snapshot” without deeply scrutinizing the diff? The bug is now baked into your new golden master. The snapshot test, which was supposed to protect you, has now actively hidden a regression.

This problem is exacerbated in large codebases with many developers. Imagine a pull request that introduces a legitimate UI change. The snapshot tests fail. Another developer, perhaps less familiar with the context, sees the diff and the failing tests. Do they spend time meticulously comparing the old snapshot with the new one, understanding the implications? Or do they trust their colleague and hit “update snapshot”? More often than not, it’s the latter. The test becomes a rubber stamp for changes, not a guardrail against errors.

When Does It Make Sense?

I’m not saying snapshot testing is never useful. There are niche scenarios where it can be beneficial, primarily for testing the exact output of APIs or very stable, complex data structures where you want to ensure the format never changes unexpectedly. For instance, testing a serializer function:

1
function serializeUser(user) {
2
  return JSON.stringify({
3
    id: user.id,
4
    username: user.username.toUpperCase(),
5
    registeredAt: user.registeredAt.toISOString()
6
  });
7
}
8

9
it('serializes user correctly', () => {
10
  const user = {
11
    id: 123,
12
    username: 'alice',
13
    registeredAt: new Date('2023-01-15T10:00:00Z')
14
  };
15
  expect(serializeUser(user)).toMatchSnapshot();
16
});

In this case, if the serializeUser function changes its output format (e.g., stops capitalizing the username or changes the date format), that’s a regression that should be caught. The snapshot serves a good purpose here because the exact string output is the contract.

The Better Alternative

For most UI components and complex objects, however, explicit assertions are far superior. Instead of matching an entire serialized tree, test the specific behaviors and properties you care about. This makes your tests more readable, more maintainable, and less prone to the “update snapshot” complacency.

For our MyComponent example, instead of a snapshot, we could write tests that assert specific things:

1
import React from 'react';
2
import { render, screen } from '@testing-library/react';
3
import MyComponent from './MyComponent';
4

5
it('displays the correct name', () => {
6
  render(<MyComponent name="Alice" />);
7
  expect(screen.getByText('Hello, Alice!')).toBeInTheDocument();
8
});
9

10
it('renders with a specific class name', () => {
11
  render(<MyComponent name="Bob" />);
12
  const component = screen.getByText('Hello, Bob!');
13
  expect(component.closest('.user-greeting')).toHaveClass('user-greeting');
14
});

These tests are clear. You know exactly what behavior is being verified. If the component breaks, the test tells you why it broke in plain English. It requires a bit more thought upfront, but the long-term benefits for code quality and developer confidence are immense. Avoid the snapshot trap; embrace explicit, meaningful assertions.