单元测试对重构的保护作用取决于其能否及时准确暴露行为偏差，关键在于覆盖边界用例、保持反馈节奏稳定、聚焦契约而非实现、重视分支与状态覆盖而非单纯行覆盖率。
单元测试对重构的保护作用，核心在于它能否在代码改动后及时、准确地暴露行为偏差。这不是靠感觉判断，而是通过可观察、可验证的信号来评估。
看测试是否覆盖关键行为边界
重构常改逻辑结构，但不该改变输入输出关系。如果测试只覆盖“正常值”，比如calculateTotal(100, 2, 0.1)，那它对重构的保护就非常有限。真正起保护作用的，是那些明确描述边界和异常的用例：
- 零值或负值输入（如
price=0、quantity=-1）是否仍抛出预期错误 - 浮点精度场景（如
taxRate=0.075）结果是否在合理误差内 - 空对象、undefined 参数等边缘输入是否被正确处理
观察重构过程中测试的反馈节奏
一次安全的重构，测试应该始终“绿着”——或者最多在极短时间内变红，且你立刻能定位到哪一行改动触发了失败。如果出现以下情况，说明测试保护力不足：
- 重构后所有测试都通过，但实际功能已悄然变化（比如四舍五入逻辑被改错，但测试没断言小数位）
- 修改一个函数内部实现，却导致多个不相关测试失败（说明测试耦合了实现细节，而非契约）
- 需要临时注释掉几个测试才能继续重构（这是危险信号，意味着测试在阻碍而非支持）
检查测试是否依赖易变的实现细节
真正保护重构的测试，应聚焦“做什么”，而不是“怎么做”。例如：
- ✅ 好的断言：
expect(result.name).toBe('Alice Smith')（关注输出结果） - ❌ 脆弱的断言：
expect(mockApiCall).toHaveBeenCalledTimes(1)（绑定具体调用次数，一旦重构中合并或拆分请求就失效） - ✅ 更健壮的方式：用 mock 隔离外部依赖，但断言最终状态或返回值，而非中间过程
用覆盖率数据辅助判断，但不迷信数字
行覆盖率 80% 不等于保护力强。重点看：
- 分支覆盖率是否达标（
if/else、switch每条路径是否都有对应测试） - 被重构的函数或组件，其参数组合、状态切换是否都被显式覆盖
- 工具如 Jest 的
--coverage --coverage-reporter=lcov可生成详细报告，直接查看高亮未覆盖的逻辑块
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
