JavaScript测试方法及常用框架教程

JavaScript测试的关键不在于是否要写测试，而在于如何聪明地选型与落地：新项目首选轻量、启动快且原生支持ESM/TS的Vitest，遗留大型项目则可延续Jest生态；测试应从纯函数、条件工具函数和逻辑清晰的Hook入手，避免过早mock和过度配置；同时需警惕模块mock写法差异、异步测试中的Promise处理陷阱，以及React环境缺失导致的ReferenceError，并通过Docker等隔离环境保障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学习网公众号，带你了解更多关于的知识点！