概要

TDD 是 测试驱动开发 (Test-Driven Development) 的缩写。它不像传统开发那样“先写代码，再补测试”，而是完全反过来的——先写测试，再写代码。

诀窍——红、绿、重构

• 红阶段：明确定义期望的行为
  • 在写任何功能代码前，先为你想添加的新功能写一个测试用例
  • 这时由于功能还没实现，测试一定会失败。在IDE里，失败通常显示为红色
  • 这一步的关键是从“使用者”的角度去定义什么是完成
• 绿阶段：编写最简单的实现代码
  • 写刚好足够让测试由红转绿的代码
  • 不需要考虑代码是否优雅，是否有重复，甚至可以用很直接的方式
  • 原则：最重要的是让测试变绿
• 重构阶段：优化代码结构与设计
  • 现在测试已经通过（有安全网了），可以大胆地优化代码结构：消除重复、改善命名、拆分长函数等。
  • 关键：重构过程中测试必须使用保持绿色，一旦变红，就说明改错了，需要立即撤销

三者以红阶段——>绿阶段——>重构阶段——>红阶段的方式循环往复

实战方式

单元测试位于金字塔底部，是最基础也最丰富的测试层。它们运行速度快、隔离性好、问题定位精确、维护成本相对较低。TDD通常被呈现为一种以单元测试为核心的方法论。

AI时代下：如果prd是确定的话（一般是需要反复修改的），用TDD的方式去进行开发，开发出的软件效果实际上是十分优异的，这得益于AI自身能够迅速生成测试用例。

另外，不是所有的代码都适合使用TDD的，如果说一个需求中包含大量的分支时，这个时候使用TDD就可以了，如果仅仅只是一个方法调用，TDD的作用就没那么大了。

小结

TDD的方式在非AI时代一定不是一个很好的开发方式，因为你提前写测试，再进行开发，所需要花费的时间一定是十分长的。因此，大部分程序员还是使用先写代码，再做测试的方式。
但是AI时代，可以一次性用AI把测试用例写出来，再通过红——>绿——>重构的方式，这样的方式可以让AI生成的代码更加的健壮，避免后期的返工。
但是实际的大型企业级项目中，prd是会不断迭代变化的，可能你白天写出来的代码，到了下午就发生了变化，这个时候前期写的大量的测试用例将会作废，反而会浪费大量的token。