为什么要 TDD（测试驱动开发）

在 Codurance，除非有非常有说服力的解释，否则不管使用什么开发语言，都是从测试开始的。

如果直接空降到这样一个环境，四周所有的人都是这么做的，自然不会有太大的阻力。但在绝大多数工作环境中，真正这么做的还是凤毛麟角，那就要好好问问这个问题，为什么需要 TDD。

在进行任何讨论前，都要从一个问句出发才能避免空对空的胡天海吹：要解决的是什么问题？

TDD，或者说软件匠艺要解决的是：如何才能让软件可以有长久的生命力，能够应对不断新增的需求，不拖业务的后腿，进而成为业务的推动力。

Agile、DevOps、软件匠艺其实都是为了解决这个问题。而 TDD 更多的是从技术角度来提供答案。

其中逻辑如此推演：

1. 为什么软件在初期能够快速应对变化，但是少则一两年后就迅速疲于应对？因为随着临时方案的堆积（tech debt)，代码很快会难以维护。

2. 怎么解决？每次增加新功能时，都要审视现有代码，通过重构确保代码质量不下降。有句话：代码的结构需要能够支持新功能顺畅地滑进去（slide）。

3. 为什么大多时候不敢重构？怕结构性地修改代码会破坏现有的功能。

4. 所以需要有多层面的自动化测试。人工回归测试的反馈周期与软件功能正比甚至多项式增加（考虑到功能之间的交互影响），无法保证快速的新需求响应。

5. 那找专人写测试确保测试覆盖率是否可以？仅仅自动化端到端的测试（end-to-end, 往往同义于黑盒或 UI 测试）可不可以？

6. 现实中维护这样的测试成本过高，而且一套测试运行下来所需要的时间过长，难以辅助到日常的重构与开发。同时，单元测试（这里特指针对最小代码单元的测试，比如一个 Java 类）并不是想写就能写的，实际碰到的代码大多根本没有考虑到可测试性。

7. 因而，从测试开始开发，至少能保证代码实现是可测试的，从而使得解决技术债务，确保快速迭代真正成为可能。

TDD 实践显然还能带来其它好处，比如用测试记录软件功能和基本单元的行为，大多情况下提供更好的代码质量（低耦合，高内聚）。但就我个人的思考来说，以上是最本质的可以追述到要解决的问题的逻辑推导。

那 TDD 难么？难。一个没有相关经验的团队，需要数月甚至半年的时间才能回归到最初的效率，这个是同事交流中得出的经验数字；因此想要推行势必要自上而下的支持。同时，除非经历过软件维护噩梦的组织，无法理解这种牺牲的必要性。但一旦过了这最初阶段，整个团队的交付速度会有质的提升，而团队成员也不再疲于奔命，整日在修 Bug、调试代码，有精力去关注更多的新工作方式与技术，工作生活的平衡也能得到改善。

我先列下为了解决同样诉求的相关的话题：

• TDD

• 重构

• 金字塔式测试

• 持续集成持续部署（CI/CD）

• 单一主线开发（trunk based development)

• 敏捷项目管理，看板，Scrum，精益制造

• 极限编程（结对编程，快速反馈等等）

• 基础设施即代码 (Infrastructure as code) ，不可更改的基础设施（Immutable infrastructure)，容器化

• 随时生产发布待命（production ready anytime），功能开关（feature flag），功能迭代

• QA 左移，安全左移，运维左移

• 自治团队

• 软件模块化，微服务化

所有的这些都构成了一个闭环，都是为了解决如何快速满足业务需求这一终极命题；同时不断也有新的方法去应对新挑战，补足现有的不足。

推荐阅读：

凤凰项目：这是一本讲述一位运维经理的偶遇宗师、传授绝学、临危受命，力挽狂澜的个人英雄主义玄幻修真小说。我的这个介绍是为了避免读者真的拿小说去生搬硬套，但是这的确是我见过最容易读进去的讲述现代 IT 运维乃至 IT 项目方法的书籍。其中涵盖了一些重要的精益制造、敏捷项目管理的知识；在通勤地铁上很容易就能看完。

最重要的是，它为困顿于现实泥沼的从业者漏出了一点希望的光亮。不愿意改变是人类的本能，唯有看到了可能性，才有动力去尝试一个短期非最优的方向。