What is snapshot testing for UI, and where does it actually pay off on mobile?

Snapshot testing is the test category people either overuse into meaninglessness or dismiss as useless — usually because they've only seen it in one of its two very different forms. It's worth separating those forms before talking about where either one earns its keep.

#Two things hide under one name

The first form, popularized by Jest for React (and ported to React Native), is a serialization snapshot: render the component tree, serialize it to a readable text representation, and diff that text against a file committed to the repo. Nothing is rendered to pixels; you're diffing a structured description of the output — props, text content, nested element names.

The second form is a visual/pixel snapshot: actually render the UI — a native view hierarchy, a Compose tree, a whole screen — to a bitmap, and diff that bitmap against a reference image. This is what tools like Paparazzi (Android, Compose and Views, no emulator needed), Roborazzi (Robolectric-based), Facebook's ios-snapshot-test-case, or Point-Free's swift-snapshot-testing library do. The comparison is genuinely visual: font rendering, spacing, colors, even sub-pixel anti-aliasing differences can trip a diff.

Both compare "what we got" against "what we approved before," and both fail the same way when something changed — the question a reviewer has to answer isn't "does this pass," it's "was this change intentional." That review discipline is the entire value proposition, and it's also exactly where teams go wrong.

#Where it actually pays off

Snapshot testing earns its keep on small, deterministic, presentation-only units — the kind of components a design system ships: a Button, a Badge, a Card, an icon at three sizes and two themes. These are cheap to snapshot because their inputs are fully controlled (you pass literal props, no live data, no timestamps), their output space is small enough that a human can actually eyeball every reference image during a PR review, and regressions in them are exactly the kind of thing that's easy to introduce accidentally and easy to miss by reading a diff of the source (a shared Theme token changes and now forty screens have a 1px different padding — you'd never catch that from code review alone).

It also pays off as a fast, deterministic substitute for a device farm during CI. Paparazzi is the clearest example: it renders Compose UI using Android's layoutlib directly on the JVM, no emulator or physical device required, so a screenshot suite that would take minutes on Firebase Test Lab runs in seconds locally and on every PR. That speed is what makes visual regression testing viable as a gate, not just a nightly job.

#Where it stops paying off

The failure mode is well known: a screen with live, non-deterministic content (timestamps, ads, personalized data, animation mid-frame) produces a snapshot that's flaky by construction, and flaky tests get muted, which quietly deletes the coverage. The other failure mode is social, not technical: once "just run update-snapshots" becomes muscle memory, a snapshot test stops being a question ("did you mean to change this?") and becomes a checkbox nobody actually reads — at that point it's providing the feeling of coverage without the substance. Deep, frequently-changing screens (a settings list mid-redesign, a chat screen) are also a poor fit — every legitimate copy tweak produces a new reference image to review, so the signal-to-noise ratio of the diffs collapses.

The practical rule senior engineers apply: snapshot the leaves (individual components, design-system primitives, small composables), not the whole tree; keep reference images small in count and reviewed like code, not rubber-stamped; and pair snapshot tests with real behavioral tests (does tapping the button call the handler?) rather than treating a passing snapshot as proof the feature works — a snapshot only proves the pixels or structure match a prior state, not that the prior state was correct.

Wrap long lines
// React Native — Jest structural snapshot with @testing-library/react-native
import { render } from "@testing-library/react-native";
import { PriceBadge } from "./PriceBadge";

describe("PriceBadge", () => {
  it("renders a discounted price consistently", () => {
    const { toJSON } = render(
      <PriceBadge amountCents={1999} originalCents={2999} currency="USD" />
    );
    expect(toJSON()).toMatchSnapshot();
  });

  it("still calls onPress when the discount ribbon is tapped", () => {
    const onPress = jest.fn();
    const { getByTestId } = render(
      <PriceBadge amountCents={1999} originalCents={2999} currency="USD" onPress={onPress} />
    );
    getByTestId("price-badge").props.onPress();
    expect(onPress).toHaveBeenCalledTimes(1);
  });
});

// Android — Paparazzi pixel snapshot for a Compose component, no emulator needed
class PriceBadgeSnapshotTest {
    @get:Rule
    val paparazzi = Paparazzi(
        deviceConfig = DeviceConfig.PIXEL_6,
        theme = "android:Theme.Material.Light.NoActionBar"
    )

    @Test
    fun `discounted price badge, light theme`() {
        paparazzi.snapshot {
            AppTheme(darkTheme = false) {
                PriceBadge(amountCents = 1999, originalCents = 2999, currency = "USD")
            }
        }
    }

    @Test
    fun `discounted price badge, dark theme`() {
        paparazzi.snapshot {
            AppTheme(darkTheme = true) {
                PriceBadge(amountCents = 1999, originalCents = 2999, currency = "USD")
            }
        }
    }
}