惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

F
Fortinet All Blogs
WordPress大学
WordPress大学
The Cloudflare Blog
云风的 BLOG
云风的 BLOG
博客园 - Franky
D
Docker
小众软件
小众软件
阮一峰的网络日志
阮一峰的网络日志
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Engineering at Meta
Engineering at Meta
MongoDB | Blog
MongoDB | Blog
U
Unit 42
M
MIT News - Artificial intelligence
B
Blog
GbyAI
GbyAI
C
Check Point Blog
P
Proofpoint News Feed
博客园 - 司徒正美
Hugging Face - Blog
Hugging Face - Blog
雷峰网
雷峰网
IT之家
IT之家
Google DeepMind News
Google DeepMind News
V
V2EX
Stack Overflow Blog
Stack Overflow Blog

Codrops

Drawing With Light: An Exploration of Lit GPU Tubes with TSL and WebGPU | Codrops Building a Real-Time 3D Face Mask with MediaPipe, Threlte and Three.js | Codrops Building an Infinite Loom: Unravelling Images into Threads with Three.js | Codrops Beyond the Luminance Ramp: A Shape-Aware ASCII Renderer in Three.js | Codrops From Rays to Meshes: Building Vercel’s Prism with vgpu | Codrops More Three.js Speakers, More Ideas from Paris | Codrops Breaking the Frame: Building a Real-Time Datamosh Effect with Three.js | Codrops Bend, Aim, Fling: Turning the Eiffel Tower into a Catapult with Three.js | Codrops Volatile Nexus: Tinkering with Glass, Caustics, Cubes and Sound in Three.js | Codrops Goodgrowth: Boot Sequences, Spinning Discs, and the Art of the Portfolio | Codrops Building a Mouse-Following Square Lens Effect with Three.js and GLSL | Codrops Blender to Three.js and Back: 10 Tips for a Better Workflow | Codrops Sixty Frames for the Record: A Three.js Game, Seven Fly-Throughs, and a Wall of CRTs | Codrops Run Rob Run: Building a Music-Reactive Goo with Three.js and WebGPU | Codrops Relighting Images with Depth Maps and Three.js | Codrops Building an Animated Testimonial Hero Using the GSAP Timeline and Dynamic CMS Data | Codrops Creativity at Enterprise-Scale, Without Compromise: The OFF+BRAND. Story | Codrops Inside HAOQI.DESIGN: Letting DOM and WebGL Share a Retro-Futurist Stage | Codrops From Motion to Meaning: Denis Avramenko’s Approach to Interactive Design | Codrops Creating an Interactive 3D Cluster with Three.js, TSL and Three Start | Codrops Exploring Procedural Geometry with Three.js and WebGPU | Codrops From Brand Systems to Cultural Worlds: Inside Antinomy and 27b | Codrops Designing a Flexible Digital Archive for Chems.Studio’s Creative Practice | Codrops The Department Is Open: Building the PX PUSH Website | Codrops Garden Anomaly: A Tiny WebGPU and TSL Experiment | Codrops A Canvas for Individuality: Creating Websites That Feel Unmistakably Human with Readymag | Codrops Building an Endless Interactive Glass Xylophone with Three.js | Codrops The Story Is in the Interaction: Bonhomme’s Digital Experiences for Luxury Brands | Codrops Building an Infinite GSAP Scroll Gallery with Parallax and Flip Transitions | Codrops Studio Freight: Moving Missions Forward | Codrops
Testing What Users Actually See with Vitest and Chromatic...
By Kyle Gach · 2026-06-24 · via Codrops

Add fast, stable visual testing to your Browser Mode component tests

chromatic visual testing vitest

Vitest browser test results with Chromatic plugin

Editor’s note: Today, our friends at Chromatic are sharing an early look at their new visual testing plugin for Vitest. We’re excited to feature this guest article by Kyle Gach, who walks through how visual testing complements traditional component tests and helps catch UI regressions before they reach production.

Your PR to insert an “add to favorites” button is green. Every automated test passes. CI reports no failures.

Then a user reports that the product card doesn’t look right on their phone.

The test suite verified the component logic, but missed the rendered state the user saw: the breakpoint, the spacing, the wrapping, and the final painted layout.

Your Vitest tests can’t see your UI. Visual tests close that gap.

That’s why we’re opening early access to our new Chromatic plugin for Vitest.

Two product cards. The first one is wider and looks correct. It is labeled with a green checkmark. The second one is narrower and the layout has broken. It is labeled with a red x.

Visual component tests are perfect for UI development

Visual tests are easier to write and maintain than traditional component tests. At the same time, they provide more confidence because they test more.

A traditional component test for a product card might verify that the correct title and price are rendered and the CTA has the correct text and is clickable. Visual tests go beyond that and verify that every detail of the card’s appearance is correct: the fonts in use, colors, spacing, layout, breakpoints, etc. And they cover all of that without a single assertion you have to write and maintain.

By adding visual tests to your Vitest tests, you get the best of both worlds: regular assertions for interactive behavior and non-visual output like accessibility properties plus visual tests for appearance. Users care about both, so we must test both.

Visual testing with Vitest and Chromatic

If you’re testing your components with Vitest’s Browser Mode, the Chromatic plugin can add visual tests with no required changes to your test files.

ℹ️ What’s Browser Mode?

Vitest runs in node. By default, it renders the components in your tests in node, too, using a simulated browser environment, like jsdom or happydom. Because it’s only simulated, you often need to mock various browser and DOM APIs. Or worse, skip testing your components’ use of them.

With Browser Mode, Vitest spins up a real (typically headless) browser and renders your components there. No more mocking browser APIs. You test all the ways your components interface with the real browser.

The tradeoff is fidelity vs. speed. Browser Mode tests are far more realistic and capable, but slightly slower because of the real browser.

Browser Mode is a requirement for visual testing with Vitest.

How does it work?

Getting started is as simple as registering the plugin in your Vitest config:

// vitest.config.ts
import { defineProject } from 'vitest/config';
import { playwright } from '@vitest/browser-playwright';
import { chromaticPlugin } from '@chromatic-com/vitest/plugin'; 

export default defineProject({
  plugins: [chromaticPlugin()], // 👈 Add this; no test file changes required
  test: {
    browser: {
      provider: playwright(),
      enabled: true,
      instances: [{ browser: 'chromium' }],
    },
  },
});

With the plugin in place, performing a test run will collect the rendered result at the end of each test. (You can also collect the rendered output at arbitrary points during a test.)

Then you run Chromatic, which uploads those results to the cloud, takes snapshots in parallel, computes their diffs, automatically finds and reduces flake, and finally reports the result as a PR check.

The last step is review. You approve the diffs that look correct and reject the ones that don’t. Then push the changes to fix the rejected snapshots until you’re able to approve everything and merge your PR.

How is Chromatic different than Vitest’s visual testing?

Vitest offers a built-in visual testing capability, which also requires Browser Mode. It takes screenshots of your test results, and produces diffs to review. The key difference is that it stores those screenshots in your repo, which means you must store them with git and manage updates. You also must provide the environment to capture those screenshots, which is hard to keep stable, because it can vary based on the OS, browser, installed fonts, locale, etc.

Chromatic, by contrast, collects the rendered result of your tests locally, but captures the actual visual snapshots in a stable cloud environment. This provides a number of benefits:

  • Branch-aware baselines track main and feature branches for you, so you don’t have to store them in git.
  • Cloud rendering takes snapshots in a controlled, consistent platform to reduce environmental flake
  • SteadySnap stabilizes snapshots against animation, loading variance, and capture timing.
  • Parallel snapshotting runs your visual tests as fast as possible
  • Chromatic collects the rendered HTML, CSS, and assets behind each screenshot, so you can inspect the DOM and reproduce failures without running tests locally.

Or, to summarize with a table:

ComparisonBuilt-in Vitest visual testingChromatic Vitest plugin
Requires Browser ModeYesYes
StorageIn your repoIn cloud
Browser environmentUnique to every setupStable cloud environment
ReproductionsStatic screenshotStatic screenshot & inspectable live component
Diff reviewTerminal, CI logs, PR checksPr checks, dedicated web app
Best forSolo developers, small librariesTeams with production apps, design systems

Get early access

We are opening early access to the Chromatic plugin for teams already using Vitest Browser Mode or actively moving component tests there. The beta is private, with hands-on onboarding for a limited number of teams and free snapshots while evaluating the product.

Bring a real repo, and we will validate Browser Mode collection, CI behavior, PR review, branch baselines, and debugging against it together. Early-access teams can influence the product before launch, with priority access as the beta expands.

This is a good fit if your team already uses Vitest for component tests, has started adopting Browser Mode, and wants visual regression coverage without building screenshot infrastructure around the built-in API.

Requires Vitest Browser Mode using Playwright. We’ll follow up with onboarding details.

Kyle Gach

DX engineer at Chromatic & Storybook. Working in the overlap between design, engineering, and education. Loves reading, craft cocktails, and bike rides.

Creative Spotlights

Inside the journeys and portfolios of today's most inspiring designers and developers.

Studio Stories

Discover how studios & agencies started, how they work, and what they've built.

Case Studies

Discover the ideas, design, and craft behind today’s most inspiring web experiences.