JavaScript测试必须覆盖关键路径，单元测试用Jest隔离验证函数/组件，集成测试依场景选Cypress或Vitest，重点保障跨模块数据流与副作用，函数和分支覆盖率比行覆盖率更能暴露风险。

JavaScript 代码的单元测试和集成测试不是“选做题”，而是上线前必须验证的环节；没覆盖关键路径的测试，等于把逻辑正确*给用户验证。

用 Jest 写单元测试：从函数到组件都得拆开测

单元测试的核心是隔离——只测一个函数或一个模块，外部依赖（如 API、定时器、DOM）全要 mock。Jest 是目前最顺手的选择，它内置了 jest.fn()、mockImplementation() 和 jest.mock()，不用额外配工具链。

• describe 和 it 是组织结构的基础，别为了“好看”嵌套三层以上，容易让测试用例难以定位
• 异步函数必须显式处理：用 async/await + expect(...).resolves，或者 return promise.then(...)，否则 Jest 会跳过断言直接通过
• React 组件单元测试推荐搭配 @testing-library/react，而不是直接操作 renderer 或 shallow——后者容易测“实现细节”，一改 props 结构就全红
• 避免在测试里写 setTimeout 等真实计时器，改用 jest.useFakeTimers() + jest.runAllTimers()

test('calculates total price correctly', () => {
  const result = calculateTotal({ price: 100, tax: 0.1 });
  expect(result).toBe(110);
});
test('fetches user data and returns name', async () => {
jest.mock('./api');
const { fetchUser } = require('./api');
fetchUser.mockResolvedValue({ id: 1, name: 'Alice' });
const name = await getUserDisplayName(1);
expect(name).toBe('Alice');
});

集成测试用 Cypress 还是 Vitest？看你的边界在哪

集成测试关注的是“多个模块协作是否正常”，比如表单提交 → 调 API → 更新 UI → 显示成功提示。它不 mock 接口，但可以拦截请求并返回固定响应；也不操作真实后端，但要启动前端服务或模拟服务层。

• 如果测试目标是“页面级流程”，比如登录 → 创建订单 → 查看历史，用 Cypress 更稳：它运行在真实浏览器中，能捕获网络请求、路由跳转、状态变化，且失败时自动截图录像
• 如果测试目标是“模块组合逻辑”，比如 useAuth + useApi + FormProvider 在一起是否触发正确副作用，用 Vitest 配合 msw（Mock Service Worker）更轻量、启动更快
• Cypress 默认不支持 ESM，遇到 import.meta.url 报错，得在 cypress.config.ts 里设 supportFile: false 并手动引入初始化逻辑
• 别在集成测试里重复单元测试已覆盖的分支逻辑，重点放在跨模块的数据流和副作用上

beforeEach 和 afterEach 不只是清理 DOM，更要重置全局状态

测试之间互相污染是最隐蔽的失败原因。DOM 没清干净可能让下一个测试拿到错误的 document.querySelector 结果；但更危险的是全局变量、单例、缓存、事件监听器没重置。

• React 测试中每次用 render() 前，确保调用 cleanup()（@testing-library/react 已自动集成），否则旧组件的 effect 可能还在执行
• 用了 localStorage 或 sessionStorage 的逻辑，必须在 beforeEach 里 clear()，否则测试顺序会影响结果
• 如果项目用了 axios，在 beforeEach 中执行 axios.reset()（需先 jest.mock('axios')），否则上一个测试 mock 的响应会残留
• 自定义 Hook 测试中，若内部用了 useState 或 useRef，不要复用同一个 render 函数实例，每次测试应新建

覆盖率数字没意义，但 branch 和 function 覆盖率值得盯

Jest 的 --coverage 会输出四类指标：lines、statements、functions、branches。其中 lines 最容易虚高——空行、注释、花括号都算“执行了”。真正暴露风险的是后两者。

• functions 覆盖率低，说明有导出函数完全没被调用，可能是废弃代码，也可能是入口缺失（比如某个按钮点击事件根本没写测试）
• branches 覆盖率低，代表 if/else、switch、三元表达式里的某些分支永远没走，常见于错误处理路径、权限校验失败、API 返回异常数据等场景
• 别为提升覆盖率硬写“无意义断言”，比如对一个纯渲染组件只测 toBeInTheDocument，却不验证 props 是否影响内容；这类测试后期维护成本高，还掩盖真实缺陷
• 用 /* istanbul ignore next */ 标记真正无法测试的代码（如 UA 判断、window.location.reload()），但每处都要加注释说明为什么忽略

测试不是越全越好，而是关键决策点、外部交互点、易错分支点必须被验证。漏掉一个 catch 块，线上就可能静默失败；mock 错一个返回结构，集成环境就可能爆红。这些地方，比覆盖率数字重要得多。