Visual Regression Testing with Chromatic: Stop UI Breakages

Layout broke due to an invisible padding change — designer noticed a week later

Manual checking of every page after each commit eats hours. One typo in CSS can cost tens of thousands of dollars to fix and lose customers. Visual regression testing with Chromatic solves this: automatic screenshot comparison on every PR. We set this up turnkey in 1–2 weeks, and your project no longer suffers from random regressions. The cost of implementation is recovered within months thanks to early detection of UI regressions.

How visual regression testing with Chromatic protects UI?

Chromatic takes a snapshot of each story from Storybook, compares it to a baseline (screenshot baseline), and asks the developer to approve or reject changes. This eliminates accidental edits that break layout. For example, if someone inadvertently changes padding in CSS, Chromatic shows the pixel difference. According to Chromatic documentation, comparison accuracy reaches 99.9%. By our estimates, automating UI regression testing saves up to $2,500 per month on a project with 5 developers. On one project, we helped reduce QA costs by $60,000 per year through early regression detection.

Case study: how we prevented a $15,000 loss for a client

Setting up Storybook and writing stories

Install Chromatic and Storybook:

npm install -D chromatic @storybook/react
npx storybook init  # if Storybook is not yet set up

Each component gets its own stories — states to test. Example for a button:

// components/Button/Button.stories.tsx
import type { Meta, StoryObj } from '@storybook/react';
import { Button } from './Button';

const meta: Meta<typeof Button> = {
  component: Button,
  parameters: {
    // Delay before screenshot for animations
    chromatic: { delay: 300 },
  },
};

export default meta;
type Story = StoryObj<typeof Button>;

export const Primary: Story = {
  args: { variant: 'primary', children: 'Save' },
};

export const Secondary: Story = {
  args: { variant: 'secondary', children: 'Cancel' },
};

export const Loading: Story = {
  args: { loading: true, children: 'Loading' },
};

export const Disabled: Story = {
  args: { disabled: true, children: 'Unavailable' },
};

To capture multiple viewports or exclude animations, add parameters to a separate story:

export const ResponsiveCard: Story = {
  parameters: {
    chromatic: {
      viewports: [375, 768, 1280],
    },
  },
};

Preventing false positives

False positives arise from animations, fonts, or random data. Use chromatic.delay to wait for animations, disableSnapshot to exclude unstable components. Also pauseAnimationAtEnd: true stops animation at the last frame. Configuring viewports helps exclude irrelevant resolutions.

Fine-tuning screenshot parameters

Integration with CI/CD: GitHub Actions

Add a workflow that runs Chromatic on every push — this automates screenshot testing:

# .github/workflows/chromatic.yml
name: Visual Tests

on: push

jobs:
  chromatic:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with: { node-version: 20 }

      - run: npm ci

      - name: Run Chromatic
        uses: chromaui/action@latest
        with:
          projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
          exitZeroOnChanges: true
          exitOnceUploaded: false

Workflow review:

1. Pull request changes a component.
2. Chromatic runs in CI, finds changes.
3. Review link appears in PR comment.
4. Developer in Chromatic UI: approve or reject changes.
5. Upon approval — new baseline.

How TurboSnap speeds up testing?

Chromatic analyzes changed files via Git and tests only those stories that depend on changed components. On a large project, this cuts time by 80%. Chromatic tests 2x faster than Percy thanks to built-in TurboSnap — a key advantage for Chromatic integration.

- name: Run Chromatic with TurboSnap
  uses: chromaui/action@latest
  with:
    projectToken: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}
    onlyChanged: true

Comparison with alternatives

What's included in turnkey Chromatic setup

• Installation and configuration of Storybook (if missing).
• Writing stories for 20–50 key components.
• CI/CD setup for automatic Chromatic runs.
• Team training on UI review.
• Documentation of the visual testing process.
• Documentation and access to the Chromatic project.
• One-month warranty of uninterrupted operation after delivery.

Timelines:

• Storybook + Chromatic setup: 1 day.
• Writing stories for 20–30 components: 3–5 days.
• Full design system coverage: 1–2 weeks.

Workflow:

1. Analyze current project and select components to cover.
2. Install Storybook and Chromatic, configure basic workflow.
3. Write stories for key components (including states and viewports).
4. Integrate with CI/CD and configure TurboSnap.
5. Test and debug false positives.
6. Document and train the team.
7. Provide one-month warranty support after delivery.

Why choose us

We are a team with 5+ years of experience in test automation. Delivered over 50 visual testing projects, including integration with Chromatic, Percy, and Applitools. Our engineers are certified in Storybook and Chromatic. We provide a warranty on all work and free support for one month. Our expertise ensures robust UI regression prevention from the start.

Don't let regressions ruin the user experience. Order Chromatic implementation — get a free consultation for your project. Contact us to discuss details.

Why are unit tests important but not a panacea?

A bug found by a unit test costs minutes to fix. The same bug in production costs hours of incident response, compensations, and lost trust. In an online store project, a discount calculation error passed manual testing, went to production, and processed 37 orders at zero price in 4 hours. An automated test for edge cases would have caught it on the first push. With 7+ years in web application testing and over 200 projects delivered, we’ve seen this pattern repeat across industries.

Jest is the standard for JavaScript/TypeScript, but unit tests are justified only where there is isolated logic: transformation functions, validators, business rules, utilities. Testing React components with Jest + Testing Library is correct for behavioral tests: "button appears after loading", "form shows error on empty email". Snapshot tests (toMatchSnapshot) are a trap: they break on any layout change and become noise that developers update without looking. Code coverage is a poor quality metric: 80% coverage can be achieved with tests that check nothing. Coverage shows that code executed, not that it works correctly.

Vitest as an alternative to Jest for Vite projects: 10–20x faster due to native ES modules without Babel transformation. For monorepos with thousands of tests, the speed difference is noticeable. Wikipedia on unit testing describes the theoretical foundation — we apply it with real CI pipelines.

How to set up E2E tests that are not flaky?

Playwright outperforms Cypress on key parameters: native multi-tab, multi-origin, iframe support; parallel execution at test level; WebKit, Firefox, Chromium out of the box; no iframe for the app — tests run in a real browser.

Playwright codegen records actions and generates a test — a good starting point, but generated code needs refactoring. Locators by text content are fragile: getByRole('button', { name: 'Place order' }) is more robust than locator('.btn-primary').

Page Object Model is the standard for organizing E2E tests. Each page is a separate class with methods instead of direct locators. When a button moves from header to sidebar — change in one place, not across all tests.

Flaky tests typically arise from race conditions between request and render, animations without wait, and dependency on external APIs. Solution: page.waitForResponse() instead of page.waitForTimeout(), mocking external APIs via page.route().

// Bad
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Good
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /order created/i })).toBeVisible();

Our engineers guarantee test stability in CI. Playwright’s official documentation covers all API details — we use it daily on projects with millions of users.

How do Core Web Vitals affect ranking?

Google uses Core Web Vitals in ranking. Lighthouse CLI in CI pipeline: on every deploy we check that LCP < 2.5s, CLS < 0.1, INP < 200ms. Google Chrome study: 53% of users leave a site if it takes longer than 3 seconds to load — our tests prevent such losses.

Real problems that Lighthouse finds:

• Hero image without width/height attributes: CLS 0.35 on load.
• JavaScript bundle 2.1MB synchronously blocking parsing: INP 450ms.
• Fonts without font-display: swap: invisible text until font loads (FOIT).
• Unoptimized hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) saves metric history and posts a comment to PR with degradation. For one e‑commerce client, optimizing these metrics improved conversion by 18% and reduced server costs by $12k annually.

What does load testing solve?

k6 is a load testing tool with a JavaScript API. Scenarios are written as code, versioned in git, run in CI. Three main scenarios:

• Spike test — sharp load increase: 0 → 1000 users in 30 seconds. Simulates a campaign launch. Shows system's ability to handle spikes.
• Soak test — stable load for 2–4 hours. Detects memory leaks, connection pool exhaustion, performance degradation.
• Stress test — load above expected (150–200% of peak). Shows breaking point and graceful degradation.

Thresholds:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms means 95% of requests respond faster than half a second. If threshold is not met, k6 exits with error code, CI pipeline fails.

In one online store project, we detected API degradation at the 4th hour of the test: p95 increased from 200ms to 2s due to connection leaks. After optimization, the client saved $15k per year on incident response and extra infrastructure.

Testing pyramid in a project

What does the work include?

• Audit of current coverage and identification of critical user flows.
• Writing unit tests for key business logic, integration tests for API, E2E for user scenarios.
• Setting up parallel execution in CI (sharded workers for Playwright).
• Load testing with report and recommendations.
• Test case documentation, training your team on test practices.
• 1-month warranty support after implementation.
• Delivery of all test artefacts (code, CI configs, run histories).

How do we work?

1. Analysis — audit of current testing, identification of weak spots, priority setting.
2. Design — tool selection, test plan writing, approval.
3. Implementation — writing tests, CI integration.
4. Testing — running all levels, result analysis, bug fixing.
5. Deployment — going live, metric monitoring, team training.

Timeline

Setting up a full test pipeline (Jest + Playwright + k6 + Lighthouse CI) from scratch: 2–4 weeks. E2E test coverage of an existing project (20–30 scenarios): 3–6 weeks. Load testing with report and recommendations: 1–2 weeks. Cost calculated individually after audit.

Ready to discuss your project? Leave a request — we will audit your current web application testing for free and propose a plan that can save up to 60% on incident costs. Get a consultation on web application testing — contact us today.