Frontend Testing 2026 — Playwright / Cypress / Vitest / Jest / Storybook 9 / Chromatic Deep Comparison

Prologue — "The era of one Selenium for everything is over"

Around 2018, if you asked "what do you use for frontend testing?", the answer was simple. Jest for units, Selenium or Cypress for E2E, and BackstopJS if you bothered with visual regression at all. That was it. "Component testing" still sounded awkward, and "Storybook as test infrastructure" was an unborn idea.

As of May 2026, that picture has shattered. A typical company's frontend test pipeline looks more like this.

• Unit tests — Vitest 3 or Jest 30, paired with Testing Library.
• Component tests — Storybook 9 + Vitest, or Playwright Component Testing.
• E2E tests — Playwright 1.50+ (over half the market), Cypress 14, WebdriverIO 9.
• Visual regression — Chromatic, Percy, Applitools (SaaS) or Loki, BackstopJS, Reg-Suit (OSS).
• Network mocking — MSW (Mock Service Worker) 2.x.
• AI assistance — Playwright MCP, Browser MCP, Claude/Cursor agents writing tests directly.
• CI integration — GitHub Actions + Playwright trace + Chromatic publish.

This article maps where each of these tools stands in 2026, what they do well and badly, and which one your team should pick. Not a list, but a survey of the four currents that have rocked this market between 2024 and 2026 — Playwright's standardization, the rise of Vitest, Storybook 9 going lighter, and the new paradigm of AI agents driving the browser directly.

1. The 2026 frontend testing map — Unit / Component / E2E / Visual

First the big picture. Frontend testing splits along four axes.

Two new categories emerged between 2024 and 2026.

• Network mocking — A layer that intercepts API calls. MSW is the de facto standard.
• AI agent testing — LLMs drive the browser themselves. Playwright MCP, Browser MCP.

The 2026 trend is clear. "Bundle multiple axes into one tool." Playwright packages E2E + Component + Visual; Vitest packages Unit + Component (with Storybook). Cypress is trying similar integration but lags on speed. Either you start as a point tool and become a platform, or you arrive as a platform from day one.

The testing pyramid (lots of units, few E2E) is still valid — but in 2026 its shape has morphed. Mike Cohn's classic pyramid lost the component layer and became a "diamond" or "trophy". Component tests exploded, units thinned out to domain logic, and component tests fill the middle.

2. Playwright — the de facto standard (VS Code integration, Trace Viewer)

Playwright is Microsoft's E2E testing tool. Since 1.0 in 2020, it has rapidly taken the market. As of May 2026 it is on 1.50+, and the State of JS 2024 survey ranked it the highest in stated intent to use among E2E tools.

Core concepts

• Browser context — Each test gets an isolated browser context. Cookies and storage are sandboxed.
• Auto-waiting — Actions like click and fill wait for the element automatically. Explicit sleeps are not needed.
• Locator — A lazy object re-evaluated on each DOM query. No stale-element problems.
• Trace Viewer — Replay failed tests as snapshots, network, and console in a GUI.
• Component Testing — Mount React/Vue/Svelte components in isolation.

Strengths

• Speed — Often 2 to 3 times faster than Cypress. Supports Chromium, Firefox, and WebKit.
• VS Code extension — Author, run, and debug tests in a GUI. Codegen auto-generates them.
• Trace Viewer — Failure analysis wraps up in 30 seconds. Hard for others to imitate.
• Parallel execution — Worker distribution by default. 60% CI time reduction is common.
• Multiple pages and domains — One test can roam across origins freely.

Weaknesses

• Learning curve — Deeper abstraction than Cypress. The first few days are rough.
• Component testing went from beta to GA — GA arrived in the 1.40s, but it is still heavier than Vitest + Testing Library.
• Image comparison is weaker than SaaS — toHaveScreenshot exists, but it cannot match Chromatic or Percy's baseline management.

When to pick it

• A new project — almost always Playwright.
• You need multi-browser verification (especially Safari/WebKit).
• A large monorepo needs parallel E2E.
• A team that depends on trace-based debugging.

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test'

export default defineConfig({
  testDir: './e2e',
  fullyParallel: true,
  retries: process.env.CI ? 2 : 0,
  reporter: [['html'], ['github']],
  use: {
    baseURL: 'http://localhost:3000',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'mobile-chrome', use: { ...devices['Pixel 7'] } },
  ],
})

// e2e/checkout.spec.ts
import { test, expect } from '@playwright/test'

test('user can complete checkout', async ({ page }) => {
  await page.goto('/products/coffee-beans')
  await page.getByRole('button', { name: 'Add to cart' }).click()
  await page.getByRole('link', { name: 'Cart' }).click()
  await expect(page.getByText('Coffee Beans')).toBeVisible()
  await page.getByRole('button', { name: 'Checkout' }).click()
  await page.getByLabel('Email').fill('test@example.com')
  await page.getByRole('button', { name: 'Place order' }).click()
  await expect(page).toHaveURL(/thank-you/)
})

The real value of Playwright is the Trace Viewer. Pull the trace.zip of a CI-failed test and open it locally, and a GUI timeline replays each action's DOM snapshot, network calls, and console logs. "Why did it fail?" ends with the capture. A step above Cypress's video recording.

3. Cypress 14 — still strong

Cypress emerged around 2017 and was the standard E2E tool for a stretch. As of May 2026 it is on 14, and while it has lost share to Playwright, it still holds a large user base.

Core concepts

• In-browser test runner — Tests run inside the actual browser, with direct access to the DOM.
• Time-travel debugger — A left-side panel walks through each command's snapshot in time order.
• Real-time reload — Save the code and the test reruns immediately.
• Cypress Cloud — Cloud dashboard, parallel distribution, flaky-test detection.
• Component Testing — React/Vue/Angular components in isolation.

Strengths

• Overwhelming DX — Easy to start. cy.visit, cy.get, cy.click is intuitive.
• Time-travel debugging — Each command auto-captures a DOM snapshot. Debugging is enjoyable.
• Real-time hot reload — TDD cycle is fast.
• Rich docs and community — Stack Overflow has an answer for almost everything.

Weaknesses

• Single-domain constraint — cy.origin was added but multi-domain remains awkward.
• Weak Safari/WebKit support — Experimental, not stable.
• Speed — 30 to 50% slower than Playwright.
• Iframe handling is finicky — Pages with ads or external widgets hurt.
• Cypress Cloud pricing — Parallel runs and result retention hit free-tier limits fast.

When to pick it

• You already have a large Cypress codebase — migration is expensive.
• A single-domain SPA, small team.
• The debugging experience matters most.

// cypress/e2e/login.cy.js
describe('Login flow', () => {
  beforeEach(() => {
    cy.intercept('POST', '/api/login', { fixture: 'login-success.json' }).as('login')
    cy.visit('/login')
  })

  it('logs in with valid credentials', () => {
    cy.get('[data-cy=email]').type('user@example.com')
    cy.get('[data-cy=password]').type('s3cret!')
    cy.get('[data-cy=submit]').click()
    cy.wait('@login')
    cy.url().should('include', '/dashboard')
    cy.contains('Welcome back').should('be.visible')
  })
})

The biggest additions in Cypress 14 are WebKit GA and Component Testing UX improvements. But Playwright is already a step ahead, so the share of greenfield projects picking Cypress has been falling fast since 2024.

4. Vitest 3 — top speed that ships with Vite

Vitest is the unit-test runner Anthony Fu created in 2021. It reuses Vite's transformer and HMR. As of 2026 it is on 3.x, and it is the default unit-test runner for new JS/TS projects.

Core concepts

• Vite-native — Reuses Vite config as-is. esbuild plus Rollup transpiles.
• HMR for tests — Only changed modules are re-evaluated. Sub-second cycle.
• Jest-compatible API — describe / it / expect are almost identical to Jest.
• Workspaces — Run multiple packages of a monorepo with one vitest command.
• Browser mode — Component tests in a real browser (Playwright / WebdriverIO backend).

Strengths

• Overwhelming speed — 2 to 10 times faster than Jest. Cold start is fast too.
• Single body with the Vite ecosystem — Vite projects work without extra setup.
• TypeScript first-class — esbuild transpiles, so no detours like ts-jest.
• Optimized worker pool — Isolation via Node worker_threads plus fast execution.
• Integrates with Storybook 9 — @storybook/addon-vitest turns stories into tests.

Weaknesses

• CRA / Next.js legacy — Webpack-based projects pay a migration cost.
• JSDOM / happy-dom compatibility — Small differences in some DOM APIs.
• Jest's vast plugin ecosystem — Some mirrors like jest-extended are incomplete.

When to pick it

• Any Vite-based project.
• A new project — almost always Vitest.
• When unit-test speed matters (CI minutes saved).

// vitest.config.ts
import { defineConfig } from 'vitest/config'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  test: {
    globals: true,
    environment: 'happy-dom',
    setupFiles: ['./test/setup.ts'],
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html'],
      exclude: ['node_modules/', 'test/'],
    },
  },
})

// src/utils/format.test.ts
import { describe, it, expect } from 'vitest'
import { formatCurrency } from './format'

describe('formatCurrency', () => {
  it('formats KRW without decimals', () => {
    expect(formatCurrency(12345, 'KRW')).toBe('₩12,345')
  })

  it('formats USD with two decimals', () => {
    expect(formatCurrency(12.5, 'USD')).toBe('$12.50')
  })

  it('handles negative numbers', () => {
    expect(formatCurrency(-100, 'USD')).toBe('-$100.00')
  })
})

The biggest change in Vitest 3 is Browser mode GA. Components mount in real Chromium, not JSDOM. It overlaps with Playwright Component Testing, but feels more natural inside a Vite-based project.

5. Jest 30 — legacy plus Next compatibility

Jest is the unit-test runner Facebook built in 2014. For a long stretch it was the de facto standard for JS testing. Version 30 shipped in September 2025, and as of May 2026 the 30.x minor line has stabilized.

Core concepts

• Snapshot testing — expect(tree).toMatchSnapshot() serializes a UI tree and stores it.
• Module mocking — jest.mock() swaps an import path for a fake.
• Fake timers — jest.useFakeTimers() controls setTimeout / setInterval.
• Coverage — Istanbul-based coverage is built in.

Strengths

• Vast ecosystem — Tens of thousands of plugins like jest-extended, jest-fetch-mock.
• CRA / Next.js default integration — Next's next/jest provides standard setup.
• Stability — Ten years of vetting. High trust in large codebases.
• VS Code integration — The Jest Runner extension works well.

Weaknesses

• Speed — 2 to 5 times slower than Vitest. CI time hurts in large codebases.
• ESM support remains awkward — Some ESM packages still need hacks.
• TypeScript via ts-jest or babel — Slower than Vitest's esbuild.

When to pick it

• You already have a large Jest codebase.
• Next.js below 12 or a Webpack-based CRA.
• You depend on Jest-only plugins.

// jest.config.js
const nextJest = require('next/jest')

const createJestConfig = nextJest({ dir: './' })

const customConfig = {
  setupFilesAfterEach: ['<rootDir>/jest.setup.js'],
  testEnvironment: 'jsdom',
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/src/$1',
  },
  collectCoverageFrom: [
    'src/**/*.{ts,tsx}',
    '!src/**/*.stories.tsx',
  ],
}

module.exports = createJestConfig(customConfig)

The headline changes in Jest 30 are stabilized first-class native ESM support and a 30% memory reduction. Migration cost keeps Jest in large organizations, but new projects pick Jest less and less.

6. The Testing Library philosophy — avoid implementation details

Testing Library is the library family Kent C. Dodds released in 2018, with adapters for DOM, React, Vue, Svelte, and Solid. As of 2026 it is the base layer for every component test.

Core philosophy

• "The more your tests resemble the way your software is used, the more confidence they can give you."
• Do not peek at the component's internal state — look at what the user sees and clicks.
• getByRole, getByLabelText, getByText — accessibility-based queries.
• getByTestId is a last resort.

Strengths

• Refactor-friendly — The test holds even when the internal structure of the component changes.
• Hand in hand with accessibility — ARIA-role queries verify a11y naturally.
• Framework-agnostic — Same philosophy in React, Vue, or Svelte.
• Libraries like TanStack, Mantine, Radix are built with Testing Library in mind.

Weaknesses

• Slower than pure unit tests — DOM rendering is needed.
• userEvent vs fireEvent — The two APIs confuse beginners.
• Async handling — findBy* and waitFor confuse many.

Example — React Testing Library + Vitest

import { describe, it, expect } from 'vitest'
import { render, screen } from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import { LoginForm } from './LoginForm'

describe('LoginForm', () => {
  it('shows error when password is too short', async () => {
    const user = userEvent.setup()
    render(<LoginForm onSubmit={() => {}} />)

    await user.type(screen.getByLabelText(/email/i), 'user@example.com')
    await user.type(screen.getByLabelText(/password/i), 'abc')
    await user.click(screen.getByRole('button', { name: /sign in/i }))

    expect(
      await screen.findByText(/password must be at least 8 characters/i)
    ).toBeInTheDocument()
  })

  it('calls onSubmit with valid input', async () => {
    const onSubmit = vi.fn()
    const user = userEvent.setup()
    render(<LoginForm onSubmit={onSubmit} />)

    await user.type(screen.getByLabelText(/email/i), 'user@example.com')
    await user.type(screen.getByLabelText(/password/i), 'longerpassword')
    await user.click(screen.getByRole('button', { name: /sign in/i }))

    expect(onSubmit).toHaveBeenCalledWith({
      email: 'user@example.com',
      password: 'longerpassword',
    })
  })
})

A common pitfall — exact text matches like screen.getByText("Loading...") break under i18n. getByRole("status") or a regex is safer. And data-testid="submit-button" truly is the last resort. Users never see the testid.

7. Storybook 9 (June 2025) — lighter and integrated with Vitest

Storybook is the component workshop that appeared in 2016. Version 9, released in June 2025, was a big inflection. It got lighter (about 50% smaller bundle) and deeply integrated with Vitest.

Headline changes (Storybook 9)

• Lighter weight — The 9.0 announcement cited "up to 75% fewer dependencies and 48% lighter install."
• Vitest-based testing — @storybook/addon-vitest makes a story a test.
• Component testing — Play functions are the de facto interaction-test standard.
• Built-in visual testing — Smoother Chromatic integration.
• Built-in a11y checks — @storybook/addon-a11y is on by default.

Strengths

• Write once, use many ways — A single story covers the catalog, interaction tests, visual regression, and a11y.
• Collaboration with designers — Figma integration. Live-check design tokens.
• Vitest integration — Running a story uses the same infrastructure as a unit test.
• Plugins / Addons ecosystem — addon-controls, addon-actions, addon-docs.

Weaknesses

• Build time — Storybook builds take minutes in a large design system.
• CSF (Component Story Format) 3 — Has a learning curve. New teams find it awkward.
• Bundler split — Config diverges between Vite-based and Webpack-based setups.

Example — CSF 3 + play function

// Button.stories.tsx
import type { Meta, StoryObj } from '@storybook/react'
import { expect, userEvent, within } from '@storybook/test'
import { Button } from './Button'

const meta: Meta<typeof Button> = {
  title: 'UI/Button',
  component: Button,
  tags: ['autodocs'],
}
export default meta

type Story = StoryObj<typeof Button>

export const Primary: Story = {
  args: {
    variant: 'primary',
    children: 'Click me',
  },
}

export const Clicked: Story = {
  args: { variant: 'primary', children: 'Click me' },
  play: async ({ canvasElement }) => {
    const canvas = within(canvasElement)
    const btn = canvas.getByRole('button', { name: /click me/i })
    await userEvent.click(btn)
    await expect(btn).toHaveAttribute('aria-pressed', 'true')
  },
}

// vitest.workspace.ts — Storybook 9 + Vitest integration
import { defineWorkspace } from 'vitest/config'
import { storybookTest } from '@storybook/addon-vitest/vitest-plugin'

export default defineWorkspace([
  './vitest.config.ts',
  {
    extends: './vitest.config.ts',
    plugins: [storybookTest({ configDir: '.storybook' })],
    test: {
      name: 'storybook',
      browser: {
        enabled: true,
        headless: true,
        name: 'chromium',
        provider: 'playwright',
      },
    },
  },
])

The real value of Storybook 9 is "write a story once and you get the catalog, tests, visual regression, and a11y for free." Essentially mandatory for design system teams.

8. Chromatic / Percy / Applitools — visual regression

Visual regression checks pixel-by-pixel whether a UI change was intended. The three SaaS leaders are Chromatic, Percy (BrowserStack), and Applitools.

Chromatic

• Operated by the company that builds Storybook. One body with Storybook.
• Story-level visual regression is its strength.
• Cross-browser baselines stored in the cloud.
• The review workflow (diff to approve to merge) is clean.
• Pricing by snapshot — small teams get by on the free tier.

Percy (BrowserStack)

• Acquired by BrowserStack in 2017. Percy CLI integrates with Playwright, Cypress, WebdriverIO.
• Multi-viewport, multi-browser baselines.
• Hooks into BrowserStack's real-device cloud.

Applitools

• AI-based visual comparison is its strength — flags only "meaningful changes".
• The Visual AI algorithm auto-ignores dynamic content (timestamps, ads).
• Ultrafast Grid — capture once, verify across many browser and device combinations.
• Enterprise pricing. Dominant in large organizations.

Differences

// Playwright + Percy
import { test } from '@playwright/test'
import percySnapshot from '@percy/playwright'

test('homepage looks correct', async ({ page }) => {
  await page.goto('/')
  await percySnapshot(page, 'Homepage')
})

// Playwright + Applitools Eyes
import { test } from '@playwright/test'
import { Eyes, BatchInfo, Configuration } from '@applitools/eyes-playwright'

test('checkout flow visual', async ({ page }) => {
  const eyes = new Eyes()
  const cfg = new Configuration()
  cfg.setBatch(new BatchInfo('Smoke 2026-05-16'))
  eyes.setConfiguration(cfg)
  await eyes.open(page, 'Shop', 'Checkout')
  await page.goto('/checkout')
  await eyes.check('Checkout page', undefined)
  await eyes.close()
})

The biggest pitfall of visual regression is flaky snapshots. Font loading, animations, carousels, ads — leave dynamic elements unmasked and 95% of diffs are false positives. Applitools is strong because it handles this automatically.

9. Loki / BackstopJS / Reg-Suit — open-source visual regression

If SaaS is too expensive or you need to keep baselines in your own repo, there are OSS options.

Loki

• Storybook-only. loki test captures and compares all stories.
• Chromium / Firefox / WebKit. Docker-based for consistent rendering.
• Baselines commit alongside git — review happens in the PR.

BackstopJS

• The oldest open-source visual regression tool (2014).
• Puppeteer-based. Define with URL list and selectors.
• Clean HTML report. Still popular in small teams.

Reg-Suit

• OSS from Japan. Adopted by Mercari and others.
• Snapshots stored in S3 or GCS. PR diffs posted as GitHub comments.
• Captures can come from anywhere (Playwright, Cypress, Storybook).

Differences

// backstop.json — basic BackstopJS config
{
  "id": "my-project",
  "viewports": [
    { "label": "mobile", "width": 375, "height": 667 },
    { "label": "desktop", "width": 1920, "height": 1080 }
  ],
  "scenarios": [
    {
      "label": "Homepage",
      "url": "http://localhost:3000/",
      "delay": 500,
      "misMatchThreshold": 0.1
    }
  ],
  "engine": "puppeteer",
  "report": ["browser"]
}

OSS's strength is keeping baselines on your own infrastructure. Finance and healthcare often cannot use SaaS at all, so Reg-Suit or self-hosting wins there.

10. Browser MCP + Playwright MCP — AI agents driving the browser

A major shift started in late 2024. MCP (Model Context Protocol) standardized, and AI agents driving the browser directly became routine. As of May 2026 there are two camps: Playwright MCP and Browser MCP.

Playwright MCP (Microsoft)

• Microsoft's official MCP server. Exposes the entire Playwright API as MCP tools.
• Claude, Cursor, and VS Code Copilot call browser actions through it.
• Accessibility-tree based — the page is read as semantic structure, not as a screenshot.
• Works with trace capture. Tests an agent writes can be replayed in the Trace Viewer.

Browser MCP

• The OSS camp's MCP server. Multiple backends (Playwright, Puppeteer, Selenium).
• Works through a local Chrome extension inside the user's current session.
• Strong for scenarios that require being logged in.

Usage pattern

// .cursor/mcp.json — register Playwright MCP
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

After this, tell an AI agent "write and run a checkout flow test", and the agent opens the browser itself, clicks, types, and generates *.spec.ts. The next generation of Codegen.

Limits

• Flaky — Agents are non-deterministic, so the test itself may not be stable.
• Cost — LLM token cost per run.
• Security — Handing production credentials to an agent is dangerous.

So the 2026 pattern is "agent drafts → human reviews and stabilizes → register in CI". Agents are not yet running in every CI run.

11. MSW (Mock Service Worker) + a network mocking strategy

MSW is the network-mocking library Artem Zakharchenko built in 2019. As of 2026 it is on 2.x, and it is the de facto standard for network mocking in frontend tests.

Core concepts

• Service Worker-based — Intercepts at the browser's network layer. fetch, axios, XHR all work.
• Works in Node too — setupServer for Vitest / Jest.
• REST + GraphQL — Both protocols supported.
• Type-safe — Plays well with TypeScript.

Strengths

• No app code edits — Instead of jest.mock() on axios, real network calls are intercepted.
• Shared across dev, tests, and Storybook — The same handlers in three environments.
• GraphQL support — Smooth with Apollo Client and urql.
• Devtools integration — Shows up in the browser's Network tab as-is.

Example — MSW handlers

// mocks/handlers.ts
import { http, HttpResponse } from 'msw'

export const handlers = [
  http.get('/api/products', () => {
    return HttpResponse.json([
      { id: 1, name: 'Coffee Beans', price: 25000 },
      { id: 2, name: 'Tea Set', price: 35000 },
    ])
  }),

  http.post('/api/cart', async ({ request }) => {
    const body = await request.json()
    return HttpResponse.json({ ok: true, cartId: 'abc-123' }, { status: 201 })
  }),

  http.get('/api/user/me', () => {
    return new HttpResponse(null, { status: 401 })
  }),
]

// test/setup.ts — in Vitest
import { setupServer } from 'msw/node'
import { handlers } from '../mocks/handlers'
import { afterAll, afterEach, beforeAll } from 'vitest'

const server = setupServer(...handlers)

beforeAll(() => server.listen({ onUnhandledRequest: 'error' }))
afterEach(() => server.resetHandlers())
afterAll(() => server.close())

// browser entrypoint (development)
import { setupWorker } from 'msw/browser'
import { handlers } from './mocks/handlers'

if (process.env.NODE_ENV === 'development') {
  const worker = setupWorker(...handlers)
  worker.start()
}

The real value of MSW is "the same mocking code in tests, dev, and Storybook". The frontend keeps moving when the backend is not yet ready; tests and real development share the same fixtures.

Alternatives like Playwright's page.route() and Cypress's cy.intercept() exist, but they are tool-specific and not reusable. So a common hybrid keeps MSW as the lower layer with Playwright route on top for E2E.

12. Page Object / Component Testing patterns

As E2E tests grow, duplication becomes a problem. The two standard patterns in 2026.

Page Object Model (POM)

• One page equals one class. Encapsulate selectors and actions in the class.
• Inherited from the Selenium era. Still valid in 2026 for Playwright and Cypress.

// e2e/pages/CheckoutPage.ts
import { Page, Locator, expect } from '@playwright/test'

export class CheckoutPage {
  readonly page: Page
  readonly emailInput: Locator
  readonly submitButton: Locator

  constructor(page: Page) {
    this.page = page
    this.emailInput = page.getByLabel('Email')
    this.submitButton = page.getByRole('button', { name: 'Place order' })
  }

  async goto() {
    await this.page.goto('/checkout')
  }

  async fillEmail(email: string) {
    await this.emailInput.fill(email)
  }

  async submit() {
    await this.submitButton.click()
  }

  async expectSuccess() {
    await expect(this.page).toHaveURL(/thank-you/)
  }
}

// e2e/checkout.spec.ts
import { test } from '@playwright/test'
import { CheckoutPage } from './pages/CheckoutPage'

test('user completes checkout', async ({ page }) => {
  const checkout = new CheckoutPage(page)
  await checkout.goto()
  await checkout.fillEmail('user@example.com')
  await checkout.submit()
  await checkout.expectSuccess()
})

Component Testing

• Mount components in isolation and verify them.
• Playwright CT, Cypress CT, Vitest browser mode, Storybook play function.
• Sits between unit and E2E: "as fast as a unit test and as real as E2E".

When to use which

• Unit / pure functions — Vitest, JSDOM.
• Single component — Storybook + Vitest or Playwright CT.
• 2 to 3 component composition — Testing Library + Vitest.
• Whole page — Page Object + Playwright / Cypress.
• User journey — Page Object + Playwright with data isolation.

POM pitfall — over-abstract and you cannot see what the test does. "Login then Cart then Checkout" on one line reads great, but failures are hard to triage. Modest abstraction plus Playwright Trace Viewer is the sweet spot.

13. Korea / Japan case studies — Toss, Kakao, Mercari

Korea — Toss's UI testing

Toss has a frontend org of more than 100 engineers and runs its own design system (Toss DS). The patterns visible in public blogs and talks.

• Storybook + Chromatic — Every component of the design system lives in Storybook.
• Playwright — The E2E standard. Multi-browser verification.
• Vitest + React Testing Library — Component-level tests.
• Their own MSW handler library — Common fixtures tuned to Toss API patterns.
• CI blocks on visual regression — No merge without Chromatic approval.

The philosophy in Toss-blog posts like "Do we really need tests on the frontend?" is — "tests live with the design system." Strong component-level coverage means lighter page-level coverage.

Korea — Kakao's frontend

The Kakao group (Kakao, Kakao Bank, Kakao Enterprise) runs a similar stack.

• Jest or Vitest — Legacy on Jest, greenfield on Vitest.
• Lots of Cypress remains — Many codebases adopted it between 2020 and 2023.
• Migrating to Playwright — Greenfield projects and the bigger migrations.
• Kakao Bank is stricter — Financial regulation pushes them to internal infrastructure and OSS visual regression (Reg-Suit or in-house).

Japan — Mercari's component testing

Mercari has publicly described a Storybook + Vitest + Reg-Suit combination. The pattern.

• Storybook — The design system and every component.
• Reg-Suit — Visual regression, baselines in S3, auto-comments on GitHub PRs.
• Vitest or Jest — Units.
• Playwright — E2E.
• MSW — Network mocking.

Mercari Engineering Blog visual-regression posts are often cited as a real-world Reg-Suit case. Mercari's adoption is one of the reasons Reg-Suit is strong in Japan.

Conclusion — regional recommendations

14. Which stack should you pick — scenario-by-scenario guide

Scenario A — large SaaS (dozens of pages, i18n, multi-browser)

• Unit: Vitest 3 + React Testing Library
• Component: Storybook 9 + Vitest browser mode
• E2E: Playwright 1.50+ (Chromium, Firefox, WebKit, Mobile Safari)
• Visual: Chromatic or Applitools
• Network: MSW 2.x
• CI: GitHub Actions + Playwright trace + Chromatic publish + Slack on failure
• AI: Playwright MCP for new test drafts

Scenario B — design system / component library

• Unit: Vitest 3
• Component: Storybook 9 (CSF 3 + play function)
• Visual: Chromatic (one body with Storybook)
• A11y: @storybook/addon-a11y + axe-core
• Docs: Storybook autodocs
• Keep E2E minimal — A library lives or dies on component-level coverage

Scenario C — e-commerce (cart, checkout, multi-page)

• Unit: Vitest 3
• Component: Storybook 9 or Testing Library
• E2E: Playwright (Page Object pattern)
• Visual: Percy or Chromatic (mobile viewport is critical)
• Network: MSW + Playwright route hybrid
• Payment flow on isolated test accounts + Stripe test mode

Scenario D — media / content sites

• Unit: Vitest 3 (SEO meta verification)
• E2E: Playwright (together with Lighthouse CI)
• Visual: Chromatic or BackstopJS
• Network: MSW for CMS response mocking
• Performance regression matters — Playwright + Lighthouse integration

Scenario E — legacy migration (Jest + Cypress to Vitest + Playwright)

• Do not move it all at once — new code on new tools.
• Jest and Vitest coexist — incrementally with vitest run --project new.
• Leave Cypress E2E in place; only new E2E uses Playwright.
• A 12 to 18 month migration is realistic.

Cost estimate (May 2026, 50-person frontend team)

Small teams start simple — Vitest + Playwright + Chromatic free tier. Grow from there with Storybook 9 at the center of a design system, then a paid visual regression tier, then Playwright MCP to accelerate new test authoring.

Closing — "you are not buying a tool, you are buying trust"

The 2026 frontend testing market is not a single-tool tournament — it is a four-axis ensemble. Five currents are shaking it.

1. Playwright's standardization — Over 70% share of new E2E. The gap keeps widening.
2. Vitest's rise — The de facto unit runner alongside Vite.
3. Storybook 9 going lighter — The hub of design system + component test + visual regression.
4. AI agents authoring tests directly — Playwright MCP and Browser MCP go mainstream.
5. MSW's standardization — Network mocking equals MSW. Tool-independent fixtures.

The first line for a small team — npm i -D vitest @testing-library/react @playwright/test msw. These four cover 95% of cases. The next step is Storybook 9 + Chromatic, then a Playwright MCP integration.

One truth — "you are not buying a tool, you are buying the trust that when a test breaks, a real bug is being caught". Pick whatever tool you like, but if that trust runs below 90%, the test is just noise that blocks PRs. The first question of any tool evaluation is always "when this test goes red, how often was it catching a real bug?".

References

• Playwright — https://playwright.dev/
• Playwright VS Code Extension — https://playwright.dev/docs/getting-started-vscode
• Playwright Trace Viewer — https://playwright.dev/docs/trace-viewer
• Playwright Component Testing — https://playwright.dev/docs/test-components
• Playwright MCP — https://github.com/microsoft/playwright-mcp
• Cypress — https://www.cypress.io/
• Cypress 14 release notes — https://docs.cypress.io/guides/references/changelog
• Cypress Cloud — https://www.cypress.io/cloud
• Vitest — https://vitest.dev/
• Vitest Browser Mode — https://vitest.dev/guide/browser/
• Jest — https://jestjs.io/
• Jest 30 announcement — https://jestjs.io/blog/2025/06/04/jest-30
• Testing Library — https://testing-library.com/
• React Testing Library — https://testing-library.com/docs/react-testing-library/intro/
• Storybook — https://storybook.js.org/
• Storybook 9 release — https://storybook.js.org/blog/storybook-9/
• Storybook Vitest addon — https://storybook.js.org/docs/writing-tests/test-addon
• Chromatic — https://www.chromatic.com/
• Percy — https://percy.io/
• Applitools — https://applitools.com/
• Applitools Visual AI — https://applitools.com/platform/visual-ai/
• Loki (Storybook visual regression) — https://loki.js.org/
• BackstopJS — https://github.com/garris/BackstopJS
• Reg-Suit — https://github.com/reg-viz/reg-suit
• Selenium — https://www.selenium.dev/
• WebdriverIO — https://webdriver.io/
• MSW (Mock Service Worker) — https://mswjs.io/
• Model Context Protocol — https://modelcontextprotocol.io/
• State of JS 2024 — https://stateofjs.com/
• Kent C. Dodds — Testing Trophy — https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications
• Mercari Engineering Blog — https://engineering.mercari.com/en/blog/
• Toss Tech Blog — https://toss.tech/
• Kakao Tech Blog — https://tech.kakao.com/