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 是否响应更新。其余先放一放。
