关键业务测试驱动开发

它解决什么问题

关键业务逻辑（支付、结算、风控、订单状态机）一旦回归，代价极高，而这类代码往往又老又脆：测试只在 CI 里跑通，没人敢动。常见困境包括：先写实现再补测试，测试沦为实现的复述；测试依赖真实数据库、网络与时间，跑得慢且不稳定；需求变更时没人知道该改哪条断言。

它如何工作

围绕「测试先行」组织开发流程：先写一个会失败的测试，明确行为契约，再写让测试通过的最小实现，最后重构。要点包括：

• 契约优先：测试先描述外部可见行为，内部实现细节留给重构阶段
• 依赖隔离：数据库、第三方接口、时钟等外部依赖通过 mock 或 stub 隔离，保证测试确定性
• 回归安全网：每个用例对应一条可追溯的业务规则，变更时由失败测试精准定位问题
• 可执行规格：测试用例本身成为可阅读的规格文档

关键步骤：梳理业务规则 → 为单个行为写失败测试 → 最小实现使其通过 → 重构并保持全绿。

适用边界

TDD 不是银弹。UI 层、探索性原型和一次性脚本的收益有限；需求频繁到测试维护成本超过其保护价值时，应权衡投入。断言写得过多反而会变成新债务——只断言业务规则关心的输出。遗留代码改造宜从边界注入测试，逐步建立安全网，而非推倒重来。