JavaScript测试策略是动态决策系统，核心是明确测什么、怎么测、测多少；应就近组织测试文件、严格隔离依赖、按场景选工具、重质量轻覆盖率数字。
怎么组织测试文件才不会半年后找不到user.test.js
测试文件散落在src/各处，或者全堆在__tests__/里，是多数人踩的第一个坑。真实项目里，你每天要改的是product.js，而不是翻三页找product.integration.spec.js。
- 把测试文件紧挨被测模块放：
product/product.js和product/product.test.js同级 - 只在顶层设一个
__test__目录，专放跨模块的集成测试（如auth-flow.test.js）和端到端测试 - 后缀统一用
.test.js，别混用.spec.js——Jest默认只认.test.js，否则要额外配testMatch
单元测试写成“调用函数+断言”就完事？错在没隔离fetch和Date.now()
很多人的sum.test.js跑得飞快，但一加个fetch或localStorage就变慢、不稳定、还污染真实环境。单元测试的命门是“隔离”，不是“能跑”。
- 所有外部依赖必须 mock：
jest.mock('./api')或jest.useFakeTimers() - 异步测试必须显式处理：用
await expect(...).resolves.toBe(...)，别漏async关键字 - 避免在测试里直接操作 DOM——用
@testing-library/react的render+screen，而不是document.querySelector
集成测试该用Cypress还是Vitest？看你在测“页面流程”还是“模块组合”
选错工具会导致 80% 的时间花在等浏览器启动或重写 mock 上。关键不是框架多酷，而是它是否匹配你的测试边界。
- 测登录 → 下单 → 支付整个链路？用
Cypress：它跑在真实浏览器里，自动捕获网络请求、路由跳转、状态变化 - 测
useAuth+useCart+ 自定义 Hook 组合后的副作用？用Vitest+msw：轻量、秒启、可精准控制响应体 - 别在集成测试里重复单元测试已覆盖的分支逻辑——重点验证数据流是否穿透、错误是否冒泡、状态是否同步
覆盖率数字高≠质量好，istanbul报95%也可能漏掉关键路径
覆盖率是提示器，不是通行证。见过太多项目为了凑 90% 覆盖率，给所有 if 分支补空测试，却漏测了 catch 块里实际会抛错的第三方 SDK 调用。
立即学习“Java免费学习笔记（深入）”；
- 优先保证核心路径覆盖：主流程、高频错误分支、边界输入（如空数组、
null、超长字符串） - 对纯计算函数（如
formatCurrency）追求接近 100%，对含副作用的模块（如initAnalytics）更应关注行为是否触发，而非行数 - 用
jest --coverage --collectCoverageFrom="src/**/*.{js,ts}"生成报告，但别把它当 KPI——它不告诉你用户点击按钮后 UI 是否卡住
git push 失败后慢慢校准。 
