17370845950

有效单元测试需明确输入、可观测输出、独立环境；优先选Vitest（Vite项目）或Jest（生态成熟）；遇ReferenceError需检查配置中globals或setupFiles。

JavaScript 单元测试的核心是「隔离验证函数行为」，不是跑通整个页面。写对的关键在于：用真实输入触发被测函数，断言其返回值或副作用是否符合预期——而不是测 DOM 渲染或网络请求（那些属于集成或 E2E 范畴）。

怎么写一个有效的单元测试？

有效测试 = 明确的输入 + 可观测的输出 + 独立的执行环境。常见失效原因是测试依赖全局状态、未 mock 外部调用、或断言了不该断言的东西。

• 只测 function 或 class 的公开方法，不测私有辅助函数（除非它们逻辑复杂且被抽离为独立模块）
• 用 jest.mock() 或 vi.mock() 拦截 fetch、localStorage、第三方库等外部依赖
• 避免在测试里写 setTimeout 或 await new Promise(resolve => setTimeout(resolve, 10))；改用 jest.runAllTimers() 或 vi.advanceTimersByTime()

• 每个 test() 块必须有且仅有一个 expect() 断言主逻辑（可额外加 1–2 个辅助断言，如调用次数）

test('sum returns correct result for positive numbers', () => {
  expect(sum(2, 3)).toBe(5);
});

test('sum handles negative input', () => {
  expect(sum(-1, 1)).toBe(0);
});

Jest 和 Vitest 怎么选？

两者都支持 describe/test/expect 语法，但底层差异影响开发体验和 CI 成本。

• Jest 是历史最久、生态最全的方案，create-react-app 默认集成，插件丰富（如 jest-circus、ts-jest），但启动慢、内存占用高
• Vitest 基于 Vite，冷启动快、HMR 支持好，原生支持 import.meta.vitest，对 TypeScript 和 ESM 友好，但部分 Jest 插件（如 jest-coverage-istanbul-reporter）需替换为 vitest-coverage-v8
• 若项目已用 Vite，优先选 Vitest；若团队熟悉 Jest 且无性能瓶颈，继续用 Jest 更稳妥

遇到 ReferenceError: beforeEach is not defined 怎么办？

这是测试运行器未正确加载全局 API 的典型表现，不是代码写错了。

• 检查 vitest.config.ts 是否漏了 globals: true 配置（Vitest）
• 确认 jest.config.js 中 setupFilesAfterEnv 引入了正确的 setup 文件（如 ['./src/setupTests.ts']）
• 确保测试文件后缀是 .test.ts 或 .spec.ts，且没被 testMatch 规则排除
• 使用 VS Code 时，别误装了 “Jest Runner” 扩展却配了 Vitest —— 扩展与运行器不匹配会导致全局函数不可见

真正难的不是写第一个 test()，而是坚持在加新逻辑前先补测试覆盖率缺口，以及学会把“不确定要不要测”的模块，拆成更小、职责更单一的函数——那才是单元测试能落地的前提。