Jest是JavaScript单元测试的首选框架，因其开箱即用、内置断言/mock/快照等功能、报错友好；配置简单（Node 14+仅需npm install jest并添加script），但需注意ESM兼容、TS/JSX支持及mock时机等常见坑。
JavaScript 单元测试不是“要不要写”，而是“用什么写、怎么写才不踩坑”。主流选择是 Jest，它开箱即用、兼容性好、报错友好，适合绝大多数项目。
为什么选 Jest 而不是 Mocha 或 Vitest？
新手容易在测试框架上纠结。Mocha 需要手动配 Chai（断言）、sinon（Mock）、babel（转译），配置成本高；Vitest 虽快且轻量，但对 Webpack 项目或老版本 Node 支持不稳定。Jest 内置全部能力，jest.mock()、jest.fn()、快照测试都直接可用，出错时的堆栈和提示也更贴近开发者直觉。
- Node 14+ 项目，
npm install --save-dev jest后加一行"test": "jest"到package.json就能跑 - 遇到
ReferenceError: require is not defined？说明你在 ESM 模式下用了 CommonJS 风格的require—— 改用import，或在jest.config.js中设moduleFileExtensions: ['js', 'mjs', 'cjs'] - Jest 默认不处理
.ts或 JSX，需额外装ts-jest或babel-jest，但配置项只需加两行
如何为一个纯函数写可信赖的测试？
以 sum(a, b) 为例，重点不是“覆盖所有分支”，而是验证边界和契约。Jest 的 describe/it 结构只是组织方式，真正关键的是断言是否反映函数的真实行为。
- 别只测
sum(1, 2) === 3，补上sum(-1, 1)、sum(0, 0)、sum(Number.MAX_SAFE_INTEGER, 1)—— 后者会溢出，暴露隐含风险 - 如果函数接受字符串数字（如
sum('1', '2')），测试里必须显式写出该用例，并在代码中用Number()或parseInt()明确转换逻辑，否则类型模糊会导致后期难维护 - 避免在测试里用
console.log查问题：Jest 提供jest.spyOn(console, 'log').mockImplementation(() => {})可拦截并断言输出内容
测试带副作用的函数（如调用 API 或修改 DOM）要注意什么？
这类函数不能真实触发网络请求或操作页面，必须隔离。Jest 的 jest.mock() 是最直接的方案，但要注意 mock 的时机和粒度。
立即学习“Java免费学习笔记（深入）”；
- 在测试文件顶部写
jest.mock('./api.js')，会自动替换整个模块；但如果该模块有默认导出和命名导出混用，需用jest.mock('./api.js', () => ({ fetchData: jest.fn() }))显式声明 - 不要在
beforeEach里反复jest.resetAllMocks()—— 它重置所有 mock，可能误清其他测试依赖的状态；改用jest.clearAllMocks()更安全 - DOM 操作类测试（如 React 组件）优先用
@testing-library/react，它不关心实现细节，只断言用户可见结果；直接用document.querySelector测试，容易因内部结构微调而频繁失败
最难的从来不是写第一个 test()，而是让测试在重构时不成为阻碍。比如给函数加个新参数，测试必须同步更新调用签名；又比如 mock 返回值写死成 { data: 1 }，但实际接口返回 { result: 1 }，这种不一致会在集成阶段才暴露。保持测试与生产代码的“契约同步”，比覆盖率数字重要得多。
