Snapshot Testing: When It Helps vs When It Hurts

Snapshot tests are updated without review ('jest --updateSnapshot'), becoming a no-op that only documents current behavior without catching regressions.

Use snapshots intentionally for complex serializable output; avoid them for simple values.

// BAD: snapshot of trivial output
test('user name', () => {
  expect(getUser().name).toMatchSnapshot(); // Just test the value directly!
});

// GOOD: snapshot for complex, stable serialized output
test('renders user card', () => {
  const { container } = render(<UserCard user={mockUser} />);
  expect(container).toMatchSnapshot();
});

// BETTER: inline snapshots for small outputs (visible in test file)
test('formats error message', () => {
  expect(formatError({ code: 404, path: '/api/users' }))
    .toMatchInlineSnapshot(`"Not Found: /api/users (404)"`);
});

// For React components: prefer specific assertions
test('shows loading state', () => {
  render(<UserCard loading />);
  expect(screen.getByRole('progressbar')).toBeInTheDocument();
  // Better than snapshot — explicit intent
});

Snapshots are valuable for complex, stable output that's hard to assert property-by-property. They're harmful when used as a lazy substitute for real assertions — developers approve diffs without understanding them.