TDD（测试驱动开发） 按“红—绿—重构”循环推进：先写失败的测试，再写刚好让它通过的代码，然后在测试保护下重构。它对设计的影响来自一个朴素事实——难以测试的代码往往就是设计差的代码，TDD 把“可测试性”前置成了设计约束。

具体影响：

  • 倒逼依赖反转：要在单测里隔离被测对象，就必须依赖接口、通过注入拿协作者，天然走向 IoC 与松耦合。
  • 接口先行：先写测试等于先从调用者视角设计 API，接口会更简洁、以使用场景为中心，而不是实现细节的泄露。
  • 小步演进：每次只满足一个测试，类和方法保持小而聚焦，高内聚随之形成；测试套件又成为随时重构的安全网。
  • 可执行文档：测试描述了边界条件和预期行为。

易错点与争议：TDD 不自动产生好架构，它只管微观设计，宏观分层仍需主动思考；过度 mock 会让测试与实现耦合，重构即红；对 CRUD 胶水代码教条地 TDD 性价比低。追问方向：TDD 与 BDD 的区别，以及“测试先行”如何量化地体现在圈复杂度与依赖数上。