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 结果；但更危险的是全局变量、单例、缓存、事件监听器没重置。
立即学习“Java免费学习笔记（深入）”；
- 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 错一个返回结构，集成环境就可能爆红。这些地方，比覆盖率数字重要得多。
