1.1 统一的转换管线#

在 Jest 中，我们需要配置 babel-jest 或 ts-jest 来处理代码转换，这往往导致测试环境与生产环境的编译行为不一致。Vitest 直接调用 Vite 的 dev server 逻辑，确保测试运行在与开发环境完全相同的代码路径上。

graph TD
    subgraph Traditional ["Traditional (Jest)"]
        J_Code[Source Code] --> J_Babel[Babel/ts-jest]
        J_Babel --> J_Runtime["Node.js Runtime"]
    end
    subgraph Modern ["Modern (Vitest)"]
        V_Code[Source Code] --> V_Vite[Vite Pipeline / esbuild]
        V_Vite --> V_Runtime["V8 / Node.js"]
        V_Vite --> V_HMR[Instant HMR]
    end

1.2 性能优势：esbuild 与并行化#

Vitest 利用 esbuild 进行极速转换，并基于 tinypool 实现多线程并行执行。对于拥有数千个单元测试的项目，冷启动时间通常能显著缩短。

1
// vitest.config.ts 深度配置示例
2
import { defineConfig } from 'vitest/config';
3

4
export default defineConfig({
5
  test: {
6
    // 启用多线程并行
7
    threads: true,
8
    // 模拟浏览器环境
9
    environment: 'jsdom',
10
    // 自动清理 mock
11
    restoreMocks: true,
12
    // 覆盖率配置
13
    coverage: {
14
      provider: 'v8',
15
      reporter: ['text', 'json', 'html'],
16
      all: true,
17
    },
18
    // 针对大型项目的分片执行
19
    shard: {
20
      index: 1,
21
      size: 4,
22
    }
23
  },
24
});

2.1 为什么 Jest 必然会 OOM？#

Jest 为了保证每个测试文件之间互不干扰（避免你在 test A 里修改了 window.location 影响了 test B），它在底层使用了 Node.js 的 vm 模块。 每次执行一个测试文件，Jest 就会创建一个全新的 vm 隔离沙箱，并在里面注入一整套极其庞大的 JSDOM 环境。

致命的问题在于：Node.js 的 vm 模块在频繁创建和销毁时，存在严重的内存泄漏问题（V8 引擎的 Context 无法被垃圾回收）。 只要你的测试文件够多，内存占用就会像滚雪球一样从 500MB 飙升到 4GB，直到把 CI 机器撑爆。

2.2 Vitest 的 Tinypool 线程池拯救世界#

Vitest 从一开始就吸取了 Jest 的血泪教训。它不仅抛弃了沉重的 Babel 转换，还引入了基于 Piscina 的 tinypool 架构。

在 Vitest 中，每个测试文件不再是一个沉重的 vm 沙箱，而是被分发到独立且轻量级的 Worker Threads（工作线程） 中运行。 更绝的是，Vitest 提供了 poolOptions.threads.isolate: false 和全新的 browser 模式。当你在 CI 上遇到内存瓶颈时，可以关闭严格的隔离模式，让多个测试文件在一个 Worker 内复用 V8 上下文，彻底消灭了 OOM 的可能。

1
export default defineConfig({
2
  test: {
3
    // 开启 pool 机制，告别 Jest 的 vm 内存泄漏
4
    pool: 'threads',
5
    poolOptions: {
6
      threads: {
7
        // 在极端大型项目中，可以关闭隔离以换取极致的内存和速度
8
        isolate: false,
9
      }
10
    }
11
  }
12
});

2.1 架构差异：CDP vs WebDriver#

不同于 Selenium 依赖的 WebDriver 协议，Playwright 通过浏览器底层的调试协议（如 Chrome DevTools Protocol）直接控制浏览器引擎。这种方式响应更快，且能捕获更细粒度的网络请求和控制台日志。

3.2 核心特性分析#

• 原生并发：Playwright 可以在单个进程中启动多个独立的浏览器上下文（Browser Context），实现真正的并行测试，而无需为每个测试用例启动完整的浏览器实例。
• 自动等待 (Auto-waiting)：内置了对元素可见性、可点击性的智能轮询，减少了测试脚本中的 sleep 或手动等待逻辑。
• Trace Viewer：在 CI 环境失败时，Playwright 会生成完整的追踪文件，包含每一帧的 DOM 快照、网络请求和动作回放，提升调试效率。

1
// playwright.config.ts 生产级配置
2
import { defineConfig, devices } from '@playwright/test';
3

4
export default defineConfig({
5
  testDir: './e2e',
6
  timeout: 30 * 1000,
7
  expect: { timeout: 5000 },
8
  fullyParallel: true,
9
  forbidOnly: !!process.env.CI,
10
  retries: process.env.CI ? 2 : 0,
11
  workers: process.env.CI ? 4 : undefined,
12
  reporter: 'html',
13
  use: {
14
    actionTimeout: 0,
15
    baseURL: 'http://localhost:3000',
16
    trace: 'on-first-retry',
17
    video: 'on-first-retry',
18
  },
19
  projects: [
20
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
21
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
22
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
23
  ],
24
});

4.1 Playwright 的超能力：自动等待 (Auto-waiting)#

在以前的 Selenium 或 Cypress 时代，我们的代码里布满了丑陋的 await sleep(1000)。 Playwright 彻底改变了这一点，它内置了严格的行动前置校验 (Actionability Checks)。

当你执行 await page.locator('.submit-btn').click() 时，Playwright 会在底层以极高的频率疯狂轮询，直到满足以下所有条件才执行点击：

1. 元素存在于 DOM 中（Attached）
2. 元素是可见的（Visible，没有 display: none 或被其他元素遮挡）
3. 元素是稳定的（Stable，没有在执行 CSS transform 动画）
4. 元素接收到了指针事件（Receives Events，没有 pointer-events: none）

如果超过了 actionTimeout（默认 30 秒）还没满足，它才会报错。这直接消灭了 90% 因为时序问题导致的 Flaky Tests。

4.2 终极挑战：像素级视觉比对 (Snapshot Testing)#

在核心的 C 端业务（比如电商首页）中，仅仅断言“元素存在”是不够的。老板最怕的是：按钮在，但是 CSS 样式全乱了，字盖在了一起。

Playwright 提供了极其强大的 toHaveScreenshot 能力。但在团队协作时，一个巨大的坑是：Mac 上截的图，拿到 Linux (CI 机器) 上去比对，100% 会报错。 因为不同的操作系统、不同的显卡驱动，甚至连字体的抗锯齿边缘渲染（Anti-aliasing）都有细微的像素差异！

工业级解法：用 Docker 抹平渲染环境差异

千万不要把本地截的 Base 图片提交到 Git 仓库让 CI 去比对。 必须使用 Playwright 官方提供的 Docker 镜像来统一截图和比对环境：

1
# 1. 在本地使用 Docker 生成 Base 截图（macOS/Windows 统一用 Linux 渲染引擎）
2
docker run -v $PWD:/work/ -w /work -it mcr.microsoft.com/playwright:v1.40.0-jammy npx playwright test --update-snapshots
3

4
# 2. 在 CI (也是 Ubuntu Jammy 环境) 中执行比对
5
npx playwright test

结合代码里的容差配置：

1
import { expect } from '@playwright/test';
2

3
// 允许不超过 5% 的像素有细微的颜色偏差（解决字体抗锯齿造成的误报）
4
expect.extend({
5
  toHaveScreenshot(received, name) {
6
    return expect(received).toHaveScreenshot(name, {
7
      maxDiffPixelRatio: 0.05,
8
    });
9
  },
10
});

通过 Docker 容器化 + 合理的抗锯齿容差，你可以把 E2E 测试推进到“视觉无损”的最高境界。