主题
React 项目实践
如何搭建 React 项目的测试体系？
测试策略要覆盖用户关键路径和高风险边界，同时避免让测试绑定到组件内部实现。
面试官想考什么
- 单元测试和组件测试如何分工？ 考察测试边界。
- 什么功能必须做 E2E？ 考察风险和投入判断。
- 如何减少 flaky test？ 考察测试工程能力。
- 如何测试异步、权限和错误边界？ 考察生产场景覆盖。
一句话回答
text
React 测试应以用户行为和领域逻辑为中心，单元测纯逻辑，组件测交互，集成测边界，E2E 覆盖关键旅程和真实部署链路。面试回答详解
1. 分层策略
- 单元测试：校验、状态机、格式化、权限策略等纯逻辑。
- 组件测试：点击、输入、loading、error、键盘和可访问性。
- 集成测试：组件与请求层、路由、缓存和权限边界协作。
- E2E：登录、支付、发布、上传等高价值用户旅程。
2. 测试原则
优先查询可见文本、角色和用户动作，少依赖 className、内部 state、组件实例和 DOM 层级。测试应验证契约，而不是锁死实现。
3. 异步和不确定性
网络使用受控 mock 或契约测试，时间使用 fake clock，数据库和对象存储隔离。覆盖慢响应、失败、重试、取消、并发点击、权限变化和错误恢复。
4. 质量门禁
CI 运行类型检查、lint、单元和组件测试；关键路径运行 E2E 和视觉回归。指标看缺陷逃逸率、flaky 率、执行时间、覆盖的业务风险，而不是单纯追求行覆盖率。
可直接背诵的 30 秒回答
text
我会按风险分层：纯逻辑用单元测试，组件用用户行为和可访问性测试，集成测试覆盖请求、路由、缓存和权限边界，E2E 覆盖关键业务旅程。异步场景要控制时间、网络和数据隔离，避免测试依赖内部实现，并用 flaky 率、缺陷逃逸率和关键路径覆盖持续评估。扩展知识
关键测试矩阵
text
正常 -> 空数据 -> 慢请求 -> 失败 -> 重试 -> 权限拒绝 -> 恢复面试官追问链
追问一：为什么不追求 100% 覆盖率？
- 考察点：是否理解指标的局限。
- 回答方向：覆盖率不代表风险覆盖；应优先覆盖关键路径、复杂分支和历史回归点，并控制测试维护成本。
追问二：E2E 经常失败但本地无法复现怎么办？
- 考察点：测试排障能力。
- 回答方向：保留视频、网络、日志、版本和环境信息，消除时间等待和共享数据竞争，使用稳定 fixture 和重试只作为兜底。
追问三：如何测试权限？
- 考察点：是否只测 UI。
- 回答方向：组件测按钮和导航体验，集成/E2E 测真实请求被拒绝和正确降级，服务端授权规则用契约和后端测试保障。