[辩论] TDD（测试驱动开发）

 

The moment you know what to fear, is the moment you know what to test.

TDD（测试驱动开发）

 

 

起源于90年代nasa对于水星计划的 项目管理

 

 

rational unified process

统一软件开发过程

 

面向客户接受式测试

 

在现实需求前 没有捷径

 

用容器技术， 整个测试 都在本地 模拟用户可能的行为

 

 

反方

 为何许多程序员抗拒编写和维护测试，剖析其背后的根本矛盾——将不断变动的需求视为固定常量的谬误。

尽管TDD曾被视为极客信仰，试图通过提前编码测试“预演”未来实现，实则因忽视需求动态性导致实践困境。

真正有效的测试应贴近真实用户行为，在系统初步成型后再开展，结合容器化环境与属性基础测试，实现高效、高保真的自动化验证。

 

要点:  

- 测试不应前置为强制指令，而应在系统具备雏形后，依据真实使用场景构建，更具实效  

- ⚠️ TDD将测试置于绝对优先地位，易引发代码僵化，因测试与实现高度耦合  

- 需求并非静态常量，盲目依赖“预期终点”会导致测试偏离真实世界，陷入无效循环  

 

- 最佳策略：先完成可用原型，再聚焦关键路径与脆弱点，“恐惧之处即是测试之始”  

- 使用容器化本地环境复现完整生产链路，搭配属性驱动测试（Property-Based Testing），自动覆盖混沌输入，提升覆盖率与可靠性  

- 测试目标不只是通过，更是保障上线安全，让人安心入眠 —— 才是真正有价值的测试哲学

 

 

正方

 

AI时代TDD可能更重要，要么通过测试生成代码，要么用来生成测试。

虽然有时写case比写代码还费时间，一些出了问题就非常要命的接口值得这么操作

 tdd 还是很有价值的，尤其是在现在的 ai 时代，tdd 结合 ai 出现了很多非常炸天的能够落地的开发方法论 ovo