前端自动化测试：Vitest 与 Playwright 实战

前端自动化测试不是大厂的奢侈品，它用 Vitest 跑单元测试、用 Playwright 跑端到端验证，把回归风险挡在合并之前。很多团队上线全靠”手动点一遍”，结果每改一处样式就心惊胆战。本文给出一套能直接落地的双引擎测试方案，覆盖单元、组件与 E2E 三层。

一、为什么前端也需要自动化测试

前端代码量大、依赖链长，组件之间互相耦合，一次重构很容易牵一发动全身。单元测试负责验证”一个函数或组件在给定输入下产出预期结果”，端到端测试负责验证”真实用户在浏览器里能走完关键路径”。两者互补：单测跑得又快又多，E2E 跑得慢但最接近真实。工程化体系里，测试是和构建、监控并列的基建，相关实践可参考前端工程化进阶：pnpm Monorepo 与微前端。

一个务实的起点：给工具函数、核心业务逻辑、关键用户路径先补测试，不要追求 100% 覆盖。覆盖率只是手段，信心才是目的。性能层面，慢测试会拖垮开发体验，这点我们后面用 Vitest 的快来解释。

测试带来的不只是 bug 减少。当团队有了稳定测试网，改代码的心理成本会骤降——你敢重构、敢升级依赖、敢删除死代码，因为失败的用例会立刻告诉你哪里动错了。这种”敢动”的能力，是工程成熟度的分水岭。反之，没有测试的项目越积越腐，最后谁都不敢碰，任何改动都靠祈祷上线无事。把测试当成护栏而非负担，团队迭代速度反而会更快。

二、Vitest：贴近 Vite 的单元测试引擎

Vitest 复用 Vite 的配置与转换管道，启动几乎零成本，原生支持 ESM、TSX 和 JSX，对 Vue、React 项目都是开箱即用。比 Jest 省去一遍打包配置，是当下前端单测的主流选择。安装与最小配置：

npm i -D vitest @vue/test-utils happy-dom

// vite.config.ts
import { defineConfig } from 'vitest/config'
export default defineConfig({
  test: {
    environment: 'happy-dom',   // 组件测试用 jsdom / happy-dom 模拟 DOM
    globals: true,              // 直接使用 describe/it/expect，无需 import
    coverage: { provider: 'v8', reporter: ['text', 'html'] }
  }
})

// package.json
// "test": "vitest",
// "test:run": "vitest run",     // CI 里用 run，确保失败即退出
// "coverage": "vitest run --coverage"

日常开发打开 watch 模式，保存即跑相关用例；提交前用 vitest run 跑全量。Vitest 默认多进程并行，速度远快于单线程方案。用 test.skipIf 或分组标记把极慢的用例隔离，必要时才全量执行，避免拖慢本地反馈。这个”快”正是它能在开发循环里存活下来的关键——慢测试再正确，也没人愿意跑。

下面是测试一个金额格式化工具函数的例子，这是最典型的纯函数单测：

// utils/format.ts
export function formatPrice(cents: number): string {
  if (cents < 0) throw new Error('金额不能为负')
  return '¥' + (cents / 100).toFixed(2)
}

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

describe('formatPrice', () => {
  it('分转元并保留两位小数', () => {
    expect(formatPrice(1999)).toBe('¥19.99')
  })
  it('零值正确', () => {
    expect(formatPrice(0)).toBe('¥0.00')
  })
  it('负数抛错', () => {
    expect(() => formatPrice(-1)).toThrow('金额不能为负')
  })
})

三、组件测试：用 Testing Library 测行为而非实现

组件测试的核心是”按用户的方式交互”，不要去断言内部 state，而是查 DOM、模拟点击、校验可访问的文本。这样即使内部重构，测试依然稳定。在 Vue3 + TypeScript 项目实战 里这种写法尤其顺手。

// Counter.spec.ts
import { render, screen, fireEvent } from '@testing-library/vue'
import Counter from '@/components/Counter.vue'

it('点击按钮计数加一', async () => {
  render(Counter)
  const btn = screen.getByRole('button', { name: /count/i })
  expect(btn.textContent).toContain('0')
  await fireEvent.click(btn)
  expect(btn.textContent).toContain('1')
})

// 关键原则：用 getByRole / getByLabelText 查询，
// 避免依赖 className 和内部结构，重构不破测试。

遇到依赖外部 API 的组件，用 vi.mock 拦截请求返回假数据，保证测试不依赖网络、不依赖后端排期。断言聚焦用户可见行为：填了邮箱、点了登录，页面出现欢迎文案——而不是去查某个内部变量的值。行为稳定，测试才抗重构。

覆盖率是质量信号而非目标。建议给核心业务组件（表单、购物车、权限开关）配组件测试，纯展示组件不必强求。

四、Playwright：真实浏览器的端到端验证

单元测试再全，也保证不了”用户真的能下单”。Playwright 启动真实 Chromium、Firefox、WebKit，模拟点击、输入、路由跳转，是最接近生产的保障。它自带自动等待与追踪（trace），调试体验远胜老一代工具。工程化选型可对照前端构建工具演进：Webpack、Vite 与 Rspack。

npm i -D @playwright/test
npx playwright install          # 拉取浏览器内核，CI 中同样需要

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

test('用户能用正确密码登录', async ({ page }) => {
  await page.goto('/login')
  await page.getByLabel('邮箱').fill('user@example.com')
  await page.getByLabel('密码').fill('secret123')
  await page.getByRole('button', { name: '登录' }).click()
  await expect(page).toHaveURL(/dashboard/)
  await expect(page.getByText('欢迎回来')).toBeVisible()
})

Playwright 的 trace viewer 是排查 E2E 失败的神器：它能回放每一步的 DOM 快照、网络请求与控制台日志，不必反复本地复现。用 test.use 切换视口与语言，用 fixtures 抽取登录态，避免每个用例都重走一遍登录流程。自动等待会在元素可操作前静默重试，大幅减少”元素还没渲染就断言”的偶发失败。

配合 前端安全实战：XSS 与 CSRF 防御 里的 CSP 策略，E2E 还能顺带验证关键安全响应头是否生效，把质量与安全一起纳入回归。性能维度上，慢的 E2E 不应阻塞日常迭代，可参考 前端性能优化：Lighthouse 90+ 到首屏 1s 把性能预算与测试门禁合并管理。

五、单测与 E2E 的分工：测试金字塔

经验法则：底层多写、顶层少写。把 70% 的精力放在单测，20% 放组件测试，10% 放 E2E 覆盖登录、下单、支付这类不能出错的核心链路。性能上，E2E 慢但不必每次本地全跑，可参考前端性能优化：Lighthouse 90+ 到首屏 1s 把测试与性能预算一起纳入门禁。

六、接入 GitHub Actions 形成质量门禁

测试只有进 CI 才有意义。把单测与 E2E 接进流水线，PR 不通过就禁止合并，才真正形成防护网。具体 CI 编排可照搬GitHub Actions 实战：从零搭建 CI/CD 流水线。

# .github/workflows/test.yml
name: test
on: [push, pull_request]
jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: npm }
      - run: npm ci
      - run: npm run test:run
      - run: npm run coverage
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: npm }
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npm run build
      - run: npx playwright test
        env: { CI: 'true' }

E2E 最慢也最贵，CI 里务必用 --shard 把用例切到多台机器并行，把 10 分钟的任务压到 2 分钟。把 unit 与 e2e 拆成两个 job：单测先给快速反馈，E2E 再兜底关键路径；任何一个挂了都直接阻断合并。缓存 node_modules 与 Playwright 浏览器，能再省下一半安装时间。门禁的粒度要恰到好处——太松没意义，太严会让开发绕着走。

七、常见坑与避坑清单

落地顺序建议：先让 vitest run 在本地绿，再补几个组件测试，最后把一条核心 E2E 接进 CI。监控测试稳定性同样重要，可结合前端性能监控：Web Vitals 与 Sentry 实战 把”测试失败率”也纳入可观测面板。测试不是上线前的负担，而是你敢快速迭代的底气。