场景

计费、折扣或状态流转代码频繁修改时，人工回归慢且容易漏边界。单元测试应在秒级反馈核心规则是否仍符合预期。

原理

“单元”是可独立验证的行为边界，不必机械等同于一个方法。测试遵循准备、执行、断言，隔离网络、时钟和随机数等不稳定依赖。TDD 用红、绿、重构循环推动接口从使用者视角形成。

设计步骤

从高变更、高故障代价的纯业务逻辑开始；为正常、边界和异常路径列用例；通过依赖注入替换外部系统；断言可观察结果而非内部调用细节；命名描述场景与预期，并让测试数据最小化。

权衡

Mock 提升速度和隔离性，但过度 Mock 会复制实现、让重构变脆。覆盖率能发现未执行代码，却不能证明断言有效。TDD 有助于设计，小型探索或胶水代码则未必值得严格先测。

实践建议

单测、集成测试和端到端测试分层使用；禁止真实等待与共享可变数据；失败信息要能直接定位业务条件。修复线上缺陷时先写复现测试。评审关注场景质量而非数字，持续删除重复和无价值测试，保证套件始终快速可信。

落地检查

上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志和指标彼此对应；在预发布环境模拟依赖不可用、进程重启和配置回滚，验证降级路径不会放大故障。上线时采用小流量观察，提前定义停止条件与负责人。稳定后复盘真实数据，删除没有收益的复杂度，并把新发现的约束补进测试、监控和设计记录，使方案能够随业务持续演进，而不是停留在一次性评审结论。