有效单元测试需明确输入、可观测输出、独立环境；优先选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 的典型表现，不是代码写错了。
立即学习“Java免费学习笔记（深入）”；
- 检查
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()，而是坚持在加新逻辑前先补测试覆盖率缺口，以及学会把“不确定要不要测”的模块，拆成更小、职责更单一的函数——那才是单元测试能落地的前提。
