Trusting the Pixels: A Snapshot Testing Turn

Context: This post is part of the StreamBox branch‑by‑branch series.

Each branch adds one architecture concept and stops.

[embed]GitHub - manishandroid/StreamBox Contribute to manishandroid/StreamBox development by creating an account on GitHub.github.com

Unit tests were already in place.

They validated logic.

They did not validate visuals.

That gap is where UI regressions hide.

This branch is feature/snapshot-test.

It doesn’t change behavior. It changes confidence.

The Problem This Branch Solves

Logic tests are not visual tests.

A UI can break without failing a reducer.

A layout can shift without touching a UseCase.

Manual checks don’t scale.

So this branch adds a visual safety net.

The Idea in One Line

Unit tests prove behavior. Snapshot tests protect appearance.

Why Snapshot Testing Was Added Now

The architecture is stable.

The UI structure is stable.

That matters.

Snapshot tests are noisy if the UI is still churning.

So they come after the structure settles.

This branch is the right moment.

What Snapshot Tests Protect

They protect structure:

• layout composition
• hierarchy
• spacing
• visual intent

That’s what usually regresses first.

What Snapshot Tests Do NOT Test

They do not test:

• business logic
• navigation behavior
• animations
• runtime data fetching

Those belong elsewhere.

Snapshot tests are about output.

Not behavior.

Choosing a Snapshot Testing Approach

The framework used is Paparazzi, because it renders Compose without an emulator.

Snapshots are rendered with static, deterministic state.

No ViewModels. No repositories. No DI graphs.

Fast. Hermetic. Predictable.

Scope of Snapshot Coverage

Not everything needs a snapshot.

We focus on high‑value surfaces:

• full screens
• reusable tiles
• layout anchors like top bars

These are the places regressions hurt the most.

How Snapshot Tests Fit the Test Pyramid

Unit tests stay the foundation.

Snapshot tests sit above them as a visual safety net.

They are complementary.

Not a replacement.

Snapshot Testing Anti‑Patterns Avoided

Snapshot Testing Anti‑Patterns Avoided

• snapshotting every composable
• snapshots driven by real ViewModels or repositories
• brittle pixel‑perfect assertions
• using snapshots to test logic or state transitions
• massive, unreadable diffs

These are easy traps.

This branch avoids them intentionally.

Outcome

UI changes are now safer.

Visual regressions are caught earlier.

Refactors are possible without fear.

The architecture didn’t change.

The UI didn’t change.

The confidence did.

If you want to see it

[embed]GitHub - manishandroid/StreamBox at feature/snapshot-test Contribute to manishandroid/StreamBox development by creating an account on GitHub.github.com

Series Links

Previous: feature/unit-testing— Fake vs Mockk in Unit Test

[embed]Testing Isn’t a One‑Time Setup Context: This post is part of the StreamBox branch‑by‑branch series.mandroidubey.medium.com