前端单元测试为什么总是写不好：从 Jest 到 Vitest 的实践反思

一个常见的误区是，把单元测试当成“上线前的最后一道检查”。在这种思维下，测试成了业务的附属品，自然会被挤压。实际上，单元测试更应被视为一种设计工具和沟通契约。它迫使你在写函数时就思考边界条件，也让你在修改代码时能快速验证影响范围。当团队把测试从“验证环节”前置到“设计环节”时，很多写不好的问题才会暴露真实原因。

Jest 的稳定与负担：为什么老项目难以割舍

Jest 之所以能成为前端测试的事实标准，不是因为它最快，而是因为它为团队提供了一个“开箱即用”的完整方案。它自带了断言库、Mock 系统、覆盖率报告和快照测试，你不需要在 Mocha、Chai、Sinon 之间做选择。对于中大型、需要长期维护的项目，这种稳定性是无可替代的。

但这份“完整”也带来了负担。Jest 默认使用自己的模块系统和转译管道（通常是 Babel 或 ts-jest）。这意味着，如果你的项目构建工具是 Vite 或 esbuild，你就维护着两套不同的转译逻辑。这不仅增加了配置复杂度，更关键的是，它让开发环境（Vite 的热更新）和测试环境（Jest 的转译）产生了割裂。你可能会在开发时一切正常，但运行测试时却遇到模块解析错误，比如经典的 Jest encountered a declaration exception，这往往是因为 jest.config.js 中的 transform 配置未能覆盖到某些文件类型。

下面这个表格总结了 Jest 在几种典型场景下的表现：

Jest 像一位经验丰富的管家，他能帮你打理好一切，但你也必须接受他固有的工作节奏和方式。

Vitest 的突围：不止是“更快的 Jest”

Vitest 的出现，恰好击中了 Jest 在 Vite 生态中的痛点。它不是一个全新的框架，而是一个基于 Vite 的测试运行器。这意味着它直接复用了项目的 Vite 配置、插件和模块解析逻辑。对于使用 Vite 的项目，这带来了根本性的改变：开发与测试的环境终于统一了。

// vitest.config.ts 的简洁性源于与 vite.config.ts 的共享
import { defineConfig } from 'vitest/config'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  test: {
    environment: 'jsdom', // 按需配置测试环境
    globals: true, // 可选，提供类似 Jest 的全局 API
  },
})

速度是 Vitest 最直观的优势。由于利用了原生 ESM 和 Vite 的预构建，其冷启动速度远超基于转译的 Jest。更重要的是它的“监听模式”体验——得益于 Vite 的即时热模块替换，文件保存后相关测试能在毫秒级内重新运行，这种反馈速度真正让测试驱动开发变得流畅。

但 Vitest 的价值不止于速度。它迫使团队重新审视测试的定位。当测试环境与开发环境高度一致时，那些因环境差异导致的诡异 bug（比如在测试中找不到某个 Vite 插件处理的模块）会大大减少。测试从一项“特殊任务”回归到“另一种运行代码的方式”，这降低了心理负担和上下文切换成本。

选型背后的工程考量：什么时候该换，什么时候该留

从 Jest 迁移到 Vitest 听起来很诱人，但并非所有项目都适合。决策不应该基于“哪个更新、哪个更快”的简单比较，而应该基于具体的工程上下文。

考虑迁移到 Vitest，如果：

• 你的项目已经使用 Vite 构建，希望统一工具链，减少配置维护成本。
• 团队对测试速度（特别是本地开发时的反馈速度）有极高要求。
• 项目较新，尚未积累大量依赖特定 Jest 插件或复杂 Mock 的测试代码。
• 你希望更自然地测试原生 ESM 模块或 Vite 虚拟模块。

暂时留在 Jest，如果：

• 项目庞大且测试套件成熟，迁移的回归风险和人力成本过高。
• 重度依赖某些 Jest 特有生态（如特定快照序列化器、自定义报告器）。
• 团队对 Jest API 和问题排查有深厚的经验积累，切换工具的学习成本大于收益。
• 项目构建工具不是 Vite，且没有计划更换。

很多团队陷入的困境是，在项目初期没有明确测试策略，随着时间推移，测试代码和工具链都变成了“历史债务”。无论是选择 Jest 还是 Vitest，一个清晰的、与项目架构同步演进的测试策略，比工具本身更重要。

写好测试，比选对工具更难

工具解决了环境与速度的问题，但写不出好测试的核心障碍往往在于代码本身和测试观念。

障碍一：不可测试的代码结构。 如果一个函数做了十件事，依赖了三个全局状态和两次网络请求，那么为它编写独立、稳定的单元测试将是一场噩梦。单元测试写不好，常常是代码需要重构的第一个信号。遵循单一职责、依赖注入等原则，是写出可测代码的前提。

障碍二：验证实现，而非行为。 脆弱的测试往往是因为它过度关注函数内部的实现细节（比如是否调用了某个内部方法，状态是否按特定顺序变化），而不是关注函数的对外契约（给定输入，是否产生预期输出）。当实现因优化而改变时，大量测试会毫无必要地失败。

障碍三：糟糕的测试隔离。 测试之间因为共享可变状态而相互影响，是导致测试结果不稳定的常见原因。无论是 Jest 还是 Vitest，都要善用 beforeEach、afterEach 来清理状态。对于 ES 模块，有时还需要使用 jest.resetModules() 或类似机制来清除模块缓存，防止 mock 残留。

// 一个隔离性差的测试例子（假设 userService 有内部状态）
import { userService } from './userService';

it('should add user A', () => {
  userService.add('Alice');
  expect(userService.count).toBe(1);
});

it('should add user B', () => { // 这个测试可能失败，因为 userService 状态被上一个测试污染了
  userService.add('Bob');
  expect(userService.count).toBe(1); // 预期是1，实际可能是2
});

// 改进：在每个测试前重置状态
beforeEach(() => {
  userService.reset(); // 需要为服务提供重置方法
});

障碍四：忽视边界与异常。 只测试“阳光路径”是测试覆盖率虚高的主要原因。一个可靠的测试套件必须主动寻找边界：空值、非法输入、异步超时、网络错误等。测试的强度不在于行数，而在于它覆盖了多少可能出错的场景。

实践建议：让测试成为开发流程的自然部分

基于以上分析，无论团队最终选择 Jest 还是 Vitest，以下实践都能帮助提升测试的有效性：

1. 统一环境： 尽力确保测试运行环境与开发、生产环境尽可能一致。对于 Vite 项目，Vitest 是天然选择；对于其他项目，确保 Jest 的转译配置能准确反映构建行为。
2. 速度优先： 将测试运行速度作为关键指标进行优化。慢的测试不会被频繁运行。可以利用 Vitest 的并发特性，或在 Jest 中合理设置 maxWorkers。
3. 分层测试： 不要指望单元测试解决所有问题。用 Vitest 或 Jest 处理纯逻辑和组件单元测试；用 Cypress 或 Playwright 进行端到端和组件集成测试（测试真实浏览器交互）。工具各司其职。
4. 契约驱动： 在编写函数或组件接口时，同步思考其测试契约。良好的函数签名本身就能提示需要测试的输入输出情况。
5. 定期重构测试代码： 将测试代码视为与业务代码同等重要的资产，定期审查和重构，消除重复、模糊的断言，提高其表达力和可维护性。

写在最后：工具是拐杖，习惯才是腿

从 Jest 到 Vitest 的演进，反映了前端工具链对开发者体验和效率的极致追求。Vitest 凭借与 Vite 生态的深度集成，为新时代的前端项目提供了更顺畅的测试体验。然而，切换测试框架不会自动解决“写不好测试”的问题。真正的问题往往隐藏在代码结构、团队习惯和项目管理的细节中。

好的单元测试，最终体现的是一个团队对代码质量的集体承诺和工程素养。它始于一个可测试的设计，成长于持续运行的快速反馈，最终成为团队在复杂系统中安全、自信地进行更改的基石。无论你手中的工具是 Jest 还是 Vitest，关注测试本身的价值，并让它自然地融入开发节奏，才是走出“总是写不好”困境的根本路径。