Vitest Visual Testing

Deterministic Vitest captures (browser mode)

Mental model — component isolation already removed most of the flake

@uiverify/vitest archives each browser-mode test's final DOM + every resource the page loaded; UI Verify re-renders and pixel-diffs that archive server-side. Because a browser-mode component test renders an isolated component (no page scroll, no A/B / analytics / chat / consent scripts, no lazy-load-on-scroll races), you get the same head start Storybook gives you: the determinism work here is narrow. If you reach for scroll-settling or third-party stubbing, you're fighting a problem component isolation already removed (that's a real-page concern — see playwright-visual-testing).

Whatever the component is at the end of the test (or at your takeSnapshot() call) is baked into the archive forever. Your job is to drive it to one canonical state before capture.

Integration is one plugin (no per-test code):

// vitest.config.ts
import { playwright } from "@vitest/browser-playwright";
import { uiverifyPlugin } from "@uiverify/vitest/plugin";
export default defineConfig({
  plugins: [uiverifyPlugin()],
  test: {
    browser: {
      enabled: true,
      provider: playwright(),
      instances: [{ browser: "chromium" }],
    },
  },
});

Every browser-mode test then archives its final DOM automatically; takeSnapshot('name') adds an intermediate checkpoint.

UI Verify's capturer neutralizes these automatically — do NOT hand-fix them: CSS animations & transitions (killed at render) and the Web Animations API (disabled); prefers-reduced-motion: reduce (emulated); Math.random (seeded before your app code runs); web fonts and <img> loading (waited for); finite JS animations (captured at their settled final frame). And unlike a real page (playwright-visual-testing), a browser-mode test has no SSR — no server-rendered random pick to reconcile. So the checklist below is only the remainder — what lives inside your app.

The headline: freeze the data. Once the list above is off the table, the one thing left that floods a component suite with false "changes" is live/dynamic data — star counts, follower counts, contributor lists, tiles, timestamps. Feed every component static fixtures and that entire class disappears at the source: static data can't churn run-to-run, so there is nothing to diff. This is the single highest-value determinism step here — do it first (step 1), and most components need nothing else.

The one Vitest-specific trap: capture before the component settled

The auto-snapshot fires at the end of a passing test, and takeSnapshot() fires the moment you call it. If the component is still resolving a promise, running a transition, or hasn't rendered its data yet, you archive a half-rendered frame. Drive it to its final state first — await your render helper, wait for the content to appear, then let the test end (or call takeSnapshot()):

import { expect } from 'vitest';
import { render } from 'vitest-browser-react'; // or your framework's browser render helper
import { takeSnapshot } from '@uiverify/vitest';

test('user card', async () => {
  const screen = await render(<UserCard id="u_1" />); // render() is async - await it, or `screen` is a Promise
  await expect.element(screen.getByText('Ada Lovelace')).toBeVisible(); // wait for settled content
  await takeSnapshot();
});

This is the analog of a Playwright test's navigation + assertions: your render + waits are the determinism surface.

The checklist (only what the tool can't do for you)

1. Freeze the data — the one that actually matters

A component fed live/dynamic data is flaky by construction: the stars, followers, contributor list, tile order, and timestamps move between runs, so the diff lights up with no code change. Give every component static fixtures and the whole class is gone. Never let a test hit a real backend.

Concrete — feed fixed, ordered, complete fixtures:

• fixed counts (stars, followers, downloads) — literal numbers, not a live fetch;
• a fixed contributor/author list: fixed names and avatar URLs (or inlined avatars), in a fixed order;
• a fixed set of tiles/rows in a fixed order (a live "trending" sort reorders every run);
• fixed timestamps (pair with the clock, step 2).

Two ways to inject them, both fine:

// (a) pass fixtures as props — the simplest, when the component takes its data as props
await render(<LibraryTile name="ktor" stars={12873} platforms={['jvm', 'js', 'native']} />);

// (b) mock the data module the component imports — when it fetches internally
vi.mock('../api/library', () => ({ getLibrary: () => fixtures.ktor }));

If a page is a server component that fetches, render its client presentational subtree with fixture props instead of the fetching wrapper — a browser-mode test has no server to run the fetch anyway. MSW in a setup file also works for fetch-based components; the rule is only no real request.

Copy the dogfood — it's the reference implementation. apps/docs/e2e/docs-visual.browser.test.ts is the in-repo example: call takeSnapshot('name') after the page settles, with static content.

One canvas per component, not N stories. Render every variant × state of a component (a Button's sizes/states, every tile kind) in a single grid and take one snapshot — cheaper (one screenshot), and you eyeball the whole component's surface at once. Keep each page/component in its own test file so --only-changed carries the untouched ones forward, and add a path filter so the visual job only runs on UI PRs — both keep the suite cheap at scale.