多数新项目首选 jest，它开箱即用、支持快照和强 mock 能力，与 create-react-app/vite 集成顺畅；node.js 工具函数测试也推荐 jest；vitest 适合 vite 项目，启动快、hmr 友好但生态略弱。
JavaScript单元测试该用哪个框架？
多数新项目直接选 Jest，它开箱即用、支持快照、Mock 能力强，且和 create-react-app / Vite 集成顺畅。如果你在 Node.js 环境下测纯工具函数，Jest 仍是首选；若项目已重度依赖 Vitest（尤其搭配 Vite），它启动更快、HMR 友好，但生态插件略少。
别碰 Mocha + Chai + Sinon 组合——配置繁琐、断言写法松散，除非你明确需要细粒度控制测试生命周期或兼容老系统。
-
Jest默认启用jsdom，测 DOM 操作无需额外配环境 - 用
vitest时注意：某些全局对象（如TextEncoder）需手动 mock，否则跑不起来 - 避免在
beforeEach里做耗时操作（如读文件），会拖慢整个测试套件
覆盖率数字真能反映代码质量吗？
不能。80% 覆盖率可能全是 if (true) { return 'ok' } 这类无意义分支；而关键的错误路径（比如网络超时、空输入、边界值）没覆盖，100% 也没用。
真正该盯的是：分支覆盖率（branch coverage） 和 行覆盖率（line coverage） 的缺口是否集中在业务主流程、异常处理、状态转换逻辑上。
立即学习“Java免费学习笔记（深入）”；
- Jest 默认只报
lines和branches，加--coverage --coverage-reporters=html生成可视化报告，重点点开红色块看漏了哪些if/else或try/catch - 对工具函数（如
debounce、deepClone），强制覆盖所有参数组合（null、undefined、循环引用）比凑百分比重要得多 - CI 中设
--coverage-threshold={"global": {"branches": 75}}是底线，不是目标
怎么写一个不脆弱的测试用例？
脆弱测试 = 一改实现就挂，哪怕行为没变。根源常是过度依赖实现细节，比如断言了内部变量名、调用了未导出函数、或 mock 了不该 mock 的模块。
核心原则：只测 公开接口的输入输出与副作用，不关心中间怎么算的。
- 用
jest.mock('./utils')替代手写 mock 对象，防止漏掉方法或返回类型错位 - 测试异步函数时，用
await fn()+expect().resolves，别用done()回调——容易忘记调用或超时误判 - 避免在测试里写
expect(result.name).toBe('John')，如果name字段未来改成fullName，测试就崩，而行为可能完全一致 - 对 React 组件，用
@testing-library/react的screen.getByText而非container.querySelector，前者模拟用户视角，后者绑定 DOM 结构
test('calculates total with discount', async () => {
const result = calculateTotal({ items: [{ price: 100 }], discount: 0.1 });
expect(result).toBe(90); // 关注结果，不关心内部 multiply 还是 subtract
});
测试覆盖率报告里“未覆盖”的代码要不要硬补？
要看上下文。工具函数里的 throw new Error('not implemented')、TypeScript 类型守卫的 never 分支、或者明显不可能执行到的兜底 default case，可以加 // istanbul ignore next 注释跳过。
但以下情况必须补测：
-
catch块里有状态更新（如setLoading(false)）、日志上报、重试逻辑 - 条件判断中涉及外部输入（如 URL 参数、API 响应字段），且该分支被真实流量触发过
- React 组件中
{data && <list items="{data}"></list>}的data为null或undefined时的渲染 fallback
覆盖率工具只是镜子，照出盲区；人得判断那里有没有坑。
