javascript如何编写测试_有哪些测试框架【教程】

vitest 是当前 js 单元测试默认选择，因其启动快、支持 ESM/TS、HMR 热更新、API 兼容 Jest 且解耦构建工具；Jest 仅适用于存量项目或深度 CI/CD 集成；浏览器交互测试应选 Playwright 或 Cypress，而非 Jest+jsdom。

javaScript 测试不是“要不要写”，而是“怎么写才不踩坑”。直接上结论：初学者从 Vitest 入手最省力，已有项目用 Jest 仍稳妥，但别再为新项目配 Mocha + Chai + Sinon 手动组装——维护成本远超收益。

为什么 Vitest 是当前 JS 单元测试的默认选择

它复用 Vite 的解析能力，启动快、HMR 热更新测试文件、原生支持 ESM 和 typescript，且 API 高度兼容 Jest，迁移成本极低。更重要的是，它把测试运行时和构建工具解耦了，不像 Jest 那样需要模拟整个 node.js 模块系统。

• vitest 默认使用 expect 断言（和 Jest 一致），无需额外引入断言库
• 测试文件后缀可直接用 .test.ts 或 .spec.ts，Vite 会自动识别
• 跑浏览器环境测试？加 --browser 即可，不用再搭 Puppeteer 或 Playwright 脚手架
• 注意：vi.mock() 的行为和 jest.mock() 不完全一致——比如自动 mock 的路径解析更严格，遇到 “Cannot find module” 先检查是否用了相对路径或未启用 resolve.alias

Jest 还值得学吗？哪些场景绕不开它

值得，但只在两类情况：团队已有大量 Jest 测试用例；或需要深度集成 CI/CD 工具链（如 gitHub Actions 中预置的 Jest 报告插件）。Jest 的 jest.fn()、mockImplementationOnce() 在复杂副作用模拟中依然最稳定。

• 遇到 ReferenceError: jest is not defined？确认 jest 已安装且 setupFilesAfterEnv 指向了正确的初始化文件
• 测试 react 组件？优先用 @testing-library/react，而非 enzyme（已停止维护）
• Jest 的 test.each 支持模板字符串写法，但注意变量名必须和数组对象 key 严格匹配，否则报 TypeError: Cannot read Property 'x' of undefined

浏览器端交互测试该用什么框架

单元测试管逻辑，E2E 管流程，中间层（组件交互、用户行为）交给 Playwright 或 Cypress。别用 Jest + jsdom 模拟点击事件来“假装”测交互——jsdom 缺少真实 DOM 事件生命周期，focus() 不触发 focusin，change 事件不冒泡，结果不可信。

立即学习“Java免费学习笔记（深入）”；

• Playwright 跨浏览器一致性好，API 简洁，page.getByRole('button', { name: /submit/i }) 比 css 选择器更健壮
• Cypress 启动快、调试友好，但仅限 Chromium/webkit/firefox，不支持 safari 技术预览版等特殊环境
• 避免在 Playwright 中写 await page.click('#submit') —— 改用 getByRole 或 getByText，否则元素重命名或 class 变更会导致测试脆性崩溃

测试不是越全越好，关键是覆盖边界条件和副作用路径。很多人卡在“不知道该测什么”，其实就盯住三件事：函数输入非法值时是否报错、异步调用是否正确处理 reject、状态变更后 DOM 是否响应更新。其余先放一放。