17370845950

JavaScript单元测试关键在于选对框架（Jest适合CRA/webpack，Vitest适合Vite/ESM）、聚焦输入输出契约、正确mock依赖（避免复用fn、注意异步返回）、规范命名与路径（.test.ts+同目录），以实现高效可维护的测试。

JavaScript 单元测试不是“要不要写”，而是“怎么快速写出不拖慢开发、又能真正守住逻辑底线的测试”——关键在选对框架 + 用对断言 + 避开常见陷阱。

选 Jest 还是 Vitest？看你的项目类型和依赖

Jest 是目前生态最稳的选择，尤其适合已有 create-react-app 或大量 jest.mock() 需求的项目；Vitest 则更适

合 Vite 生态（vite.config.ts 已存在）、追求启动速度和 ESM 原生支持的场景。两者 API 高度兼容，但 Vitest 的 vi.mock() 行为更贴近真实模块加载顺序，而 Jest 的 jest.mock() 默认是“提升到顶部”的，容易导致未预期的 mock 覆盖。

• React + Webpack 项目 → 优先用 jest（避免配置冲突）
• Vite + TS + 组件测试多 → 用 vitest（热更新快，import.meta.vitest 开箱即用）
• 需要深度集成 Cypress 或 Playwright 做组件级快照 → vitest 的 vi.useFakeTimers() 和异步控制更灵活

test() 里该测什么？别测实现细节，只测输入输出契约

一个函数是否该被单元测试，取决于它有没有明确的输入 → 输出映射，以及是否承担业务判断逻辑。比如 formatPrice(1234.56) 应该返回 "¥1,234.56"，而不是去断言它内部调用了几次 toLocaleString()。

• 测边界值：formatPrice(0)、formatPrice(-1)、formatPrice(null)
• 测副作用触发条件：比如 handleSubmit({ email: "a@b.c" }) 是否调用了一次 api.submit()，用 expect(mockApi.submit).toHaveBeenCalledTimes(1)
• 不测 DOM 渲染细节（那是组件测试范畴），除非你用的是 @testing-library/react 并明确走 render → userEvent → assert 流程

mock 外部依赖时，jest.fn() 和 vi.fn() 的参数陷阱

mock 函数返回值写错，测试就变成“永远通过的假阳性”。最常见错误是把 mockReturnValueOnce() 写成 mockReturnValue()，导致后续所有测试用例都拿到同一个返回值，互相污染。

test('fetchUser calls api and returns data', () => {
  const mockFetch = vi.fn().mockResolvedValue({ id: 1, name: 'Alice' });
  // ✅ 正确：每次 test 都是全新 mock 实例
  vi.mock('@/api/user', () => ({ fetchUser: mockFetch }));

  await fetchUser(1);
  expect(mockFetch).toHaveBeenCalledWith(1);
});

• 不要在 beforeEach 里复用同一个 vi.fn() 实例，除非你明确要跨用例累积调用次数
• 异步 mock 必须用 mockResolvedValue() 或 mockRejectedValue()，不能只写 mockReturnValue(Promise.resolve(...))（这会让 Promise 立即执行，失去异步时序控制）
• ESM 动态导入（import(...)）下，vi.mock() 必须写在文件顶部，且不能包裹在条件中

测试文件命名和位置，直接影响可维护性

测试文件名必须以 .test.ts 或 .spec.ts 结尾，否则默认不被识别；目录结构建议与源码一一对应，比如 src/utils/formatPrice.ts 对应 src/utils/formatPrice.test.ts。这样 IDE 跳转、CI 分片、覆盖率统计才不会出错。

• 避免把所有测试塞进 __tests__/ 根目录，重构时根本找不到谁在测什么
• 组件测试文件建议和组件同名，如 Button.tsx → Button.test.tsx，便于 co-locate 和快速定位
• 如果用了 vitest 的 test.watchExclude，注意排除 node_modules 和构建产物，否则 watch 模式会卡死

最难的不是写第一个 test()，而是让团队在新增逻辑时，下意识先写测试再改代码——这靠的不是框架多强大，而是测试文件是否跟源码一样“随手可点、随手可改、出错可读”。路径对了，剩下的就是节奏问题。