Vitest比Jest更轻量、启动快、原生支持ESM/TS，新项目优先选；Jest适合大型遗留项目；测试应从纯函数、条件工具函数、逻辑明确的hook入手，避免过度mock；注意模块mock写法、异步测试await处理及React环境配置。
JavaScript 代码测试不是“要不要做”的问题，而是“用什么工具、在什么环节、测到什么程度”更实际——选错框架或过早引入复杂配置，反而拖慢开发节奏。
怎么选 Jest 还是 Vitest？
绝大多数新项目直接选 Vitest 更轻量、启动更快、原生支持 ESM 和 TypeScript；Jest 仍适合已有大型项目（尤其依赖 jest-circus 或大量自定义 setupFiles 的场景）。
-
Vitest默认复用 Vite 的解析逻辑，import.meta.url、__dirname模拟更自然，不用额外配ts-jest -
Jest的snapshot调试体验稍好，但Vitest的vitest run --watch热更新响应更快 - 若项目已用
create-react-app，别强行切Vitest——它的jest配置被深度封装，改起来反而费劲
单元测试写不下去？先从这三类函数下手
别一上来就 mock 全家桶。优先覆盖：纯计算函数、带条件分支的工具函数、有明确输入输出的 hook（如 useLocalStorage）。
- 避免测
React.render或fetch调用本身，重点测你写的逻辑分支是否触发正确副作用 - 用
vi.mock()拦截模块时，注意默认导出和命名导出写法差异：vi.mock('./api', () => ({ fetchUser: vi.fn() }))和vi.mock('./api', () => ({ default: vi.fn() }))不通用 - 异步测试别漏
await：写expect(result).resolves.toEqual(...)比expect(await result).toEqual(...)更安全，防止未 catch 的 rejected promise 导致测试静默失败
测试运行报 ReferenceError: React is not defined 怎么办？
这是组件测试最常卡住的点——不是 React 没装，而是测试环境没配好 JSX 处理链。
立即学习“Java免费学习笔记（深入）”；
- 确认
vitest.config.ts中启用了jsx: 'react-jsx'（Vitest）或transform配置了^.+\.[tj]sx?$（Jest） - 检查
package.json的type字段：设为module时，require('react')会失败，统一用import React from 'react' - 若用
@testing-library/react，确保render包裹的组件外层有<react.strictmode></react.strictmode>—— 否则某些 hooks（如useId）会抛错
真正难的不是写第一个 test，而是让测试跑在 CI 里不因环境差异失败：Node 版本、时区、process.env 初始值，都可能让本地通过的测试在服务器上飘红。每次加新测试前，先在干净 Docker 容器里跑一遍 npm test。
