JavaScript测试方法与框架大全

JavaScript测试的关键不在于是否要写测试，而在于如何聪明地选择工具（新项目首选轻量快速的Vitest，遗留大型项目可沿用Jest）、聚焦高价值场景（从纯函数、条件工具函数和逻辑清晰的Hook入手，避免过早过度Mock）、规范编写细节（注意模块Mock写法、异步测试的await处理、React环境与JSX配置），并确保测试在CI等真实环境中稳定可靠——选错框架或忽视环境一致性，反而会拖慢开发节奏。

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 处理链。

• 确认 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 包裹的组件外层有 —— 否则某些 hooks（如 useId）会抛错

真正难的不是写第一个 test，而是让测试跑在 CI 里不因环境差异失败：Node 版本、时区、process.env 初始值，都可能让本地通过的测试在服务器上飘红。每次加新测试前，先在干净 Docker 容器里跑一遍 npm test。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《JavaScript测试方法与框架大全》文章吧，也可关注golang学习网公众号了解相关技术文章。