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()，导致后续所有测试用例都拿到同一个返回值，互相污染。
立即学习“Java免费学习笔记（深入）”；
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()，而是让团队在新增逻辑时，下意识先写测试再改代码——这靠的不是框架多强大，而是测试文件是否跟源码一样“随手可点、随手可改、出错可读”。路径对了，剩下的就是节奏问题。
