JavaScript测试关键是高效可靠执行：需确保文件名含.test.js/.spec.js、describe内有it调用且含expect断言，用npx jest --verbose验证；Jest适合单元/集成测试，Vitest启动快兼容ESM，Cypress专注E2E；mock失效主因是导出方式不匹配、jest.mock()位置错误或异步处理不当。
JavaScript 代码测试不是“要不要做”的问题，而是“怎么高效、可靠地做”的问题。跳过测试直接上线，等于把验证逻辑的权力交给用户；而选错框架或配置不当，又会让测试本身变成维护负担。
怎么判断一个测试是否真的在跑 describe 和 it？
很多新手写完测试后发现 npm test 没报错但也没输出，其实是测试文件没被识别。Jest 默认只匹配 *.test.js 或 *.spec.js 后缀，且必须导出 describe/it 块（不能只是写了函数但没调用）。
- 检查文件名是否含
.test.js或.spec.js - 确认
it或test调用里有实际断言，比如expect(sum(1, 2)).toBe(3)，而不是空函数体 - 运行
npx jest --no-cache --verbose看 Jest 是否列出了匹配的测试文件 - 如果用
describe但没写it，Jest 不会报错，但该组测试不会执行——这是静默失效的常见坑
Jest、Vitest、Cypress 测试框架的核心分工差异
它们不是“谁更好”，而是“谁更适合当前场景”：
-
Jest：适合单元测试 + 集成测试，内置断言、Mock、快照，生态成熟；但启动慢、对 ESM 支持曾长期滞后（v29+ 已改善） -
Vitest：API 与 Jest 高度兼容，但基于 Vite，启动快、HMR 热更新支持好，ESM / TypeScript 开箱即用；缺点是部分 Jest 插件（如jest-circus自定义运行器）不兼容 -
Cypress：专注端到端（E2E）和组件测试，必须运行在浏览器环境；它不测纯函数逻辑，但能真实触发 DOM 事件、网络请求、路由跳转——jest模拟不了鼠标双击或beforeunload的交互细节
简单说：函数/工具类 → 用 Vitest 或 Jest；React/Vue 组件渲染逻辑 → Vitest + @testing-library；登录流程、表单提交、跨页面跳转 → Cypress。
立即学习“Java免费学习笔记（深入）”；
为什么 mock 有时不生效？关键在作用域和调用时机
Mock 失效最常见原因不是语法错，而是模块加载顺序和引用路径不一致：
- 被测模块
import { api } from './api.js'，但你在测试里jest.mock('./api.js')—— 这没问题；但如果被测模块实际走的是import api from './api.js'（默认导出），而你 mock 的是命名导出，就会失效 - 在
import语句之后才调用jest.mock()，mock 会被忽略（Jest 要求mock必须在任何相关模块import之前） - 使用
vi.mock()（Vitest）时，若模块路径是相对路径（如../utils），需确保路径相对于当前测试文件，而非vi.mock调用位置 - 异步代码中，mock 返回值是 Promise，但忘了
await或没用resolves断言，导致断言跑在 resolve 前
测试不是加了 it 就算覆盖，真正难的是让 mock 行为与真实调用链对齐、让测试错误信息能直指问题模块、让 CI 中失败的测试能在本地一键复现——这些细节比框架选型更消耗时间。
