JavaScript单元测试与集成测试需协同使用：前者隔离依赖验证单个函数逻辑（如add(2,3)===5），后者验证多模块协作（如按钮点击触发fetch并更新DOM），二者缺一不可且不可混淆。
JavaScript 单元测试和集成测试不是“选一个用”，而是解决不同层次的问题：单元测试验证 add 函数输入 2 和 3 是否返回 5；集成测试验证点击按钮后，fetch 请求是否发出、响应数据是否正确更新了 DOM。两者缺一不可，但混淆它们会导致测试脆弱或漏检。
单元测试：只测单个函数或组件的内部逻辑
单元测试的核心是隔离——用 mocks/stubs 切断外部依赖，只聚焦被测单元的行为是否符合预期。它快、稳定、定位问题直接。
- 典型场景：
calculateTotal(cartItems)是否对空数组返回0？对含税项是否正确累加？ - 必须 mock 的东西：
fetch、localStorage、第三方库（如moment）、父组件传入的回调函数 - 常见错误：没 mock
fetch，导致测试实际发请求——网络波动会让 CI 随机失败；或者 mock 了但没校验调用参数（比如没检查fetch是否用了正确的 URL） - 推荐工具组合：
Jest（开箱 mock 能力强） +@testing-library/react（测 React 组件时专注用户行为，不依赖实现细节）
test('calculates total correctly', () => {
const items = [{ price: 10, qty: 2 }, { price: 5, qty: 1 }];
expect(calculateTotal(items)).toBe(25);
});
集成测试：验证多个模块协作是否正常
集成测试不 mock 大部分依赖，允许真实模块间通信，目标是发现接口不匹配、数据流断裂、副作用遗漏等问题。它比单元测试慢，但更贴近真实运行环境。
- 典型场景：React 中点击“加载用户”按钮 → 触发
getUserById(123)→ 成功后渲染用户名和邮箱 - 关键点：保留真实
fetch（或用msw拦截并返回预设响应），不 mock 父子组件通信，允许状态管理库（如zustand或Redux）参与流程 - 容易踩的坑：把集成测试写成“端到端测试”——比如真打开浏览器、等动画、查元素位置；其实只需在 JSDOM 环境中验证 DOM 更新和事件链即可；过度 mock 又会退化成单元测试
- 推荐方式：用
@testing-library/react的render+userEvent+server.use（配合msw）
test('loads and displays user after button click', async () => {
server.use(
rest.get('/api/users/123', (req, res, ctx) =>
res(ctx.json({ id: 123, name: 'Alice', email: 'a@b.com' }))
)
);
render(
什么时候该写哪种测试？看改动影响范围
改一行工具函数逻辑？补单元测试；加一个新 API 调用链？先写集成测试；重构组件结构但不改行为？单元测试应全过，集成测试可辅助确认 UI 流程没断。
立即学习“Java免费学习笔记（深入）”；
- 单元测试覆盖率建议重点覆盖：纯函数、状态计算逻辑（如
filterItems(searchTerm, items)）、自定义 Hook 内部逻辑 - 集成测试优先覆盖：用户核心路径（登录→列表→详情→提交）、跨模块交互（表单提交触发通知 + 跳转 + 数据缓存）
- 别为“能测”而测：比如给一个只做
console.log的函数写单元测试，意义不大；但若它调用了navigator.geolocation.getCurrentPosition，那就需要集成测试来确认权限提示和坐标处理是否连贯
真正难的是边界判断——比如某个 Hook 同时封装了 fetch 和本地缓存逻辑，它算单元还是集成？答案是：按你最想保护的契约来定。如果重点是“相同输入永远返回相同输出”，就 mock 掉 fetch 和 localStorage 做单元测试；如果重点是“首次加载走网络、重复加载走缓存”，就必须让两者真实协作，用集成测试验证整个生命周期。
