Bob 大叔谈测试驱动开发的适用性

Bob Martin 之前在一篇颇有争议的博文中声称“那些认为测试驱动开发（TDD）会减缓项目进度的人都生活在石器时代”。现在，他又深入分析了测试驱动开发的现实适用性、角色和优势。

他首先提出了一个重要问题：“TDD 取代架构了吗？”。回答：“不，但是…”：

以为通过在白板上编写一个个测试用例就可以产生清晰架构的想法简直就是胡闹。你做的某些决定与测试毫无关系。 当然，很多决定可以并且应该尽可能的延期。例如，数据库模式（schema）可以等待很长时间。使用 Spring、JSF、Hibernate 和 JPA 等的决定也可以延迟做出。业务规则的魅力在于它们可以并且应该独立于数据库和 GUI 模块而实现。

…

这是底线。你不能通过 TDD 得到一个完整的架构。TDD 可以告诉你某些架构决定，但是你无法在没有架构设计的情况下启动项目。因此某些预先的架构是必要的。其中最重要的一点是决定哪些架构元素可以延迟哪些不能。

回答完架构问题，Martin 又转向了下一个话题：“TDD 能够替代设计吗？”。他的回答:

不，你仍然需要所有的设计技能。你仍然需要了解设计原则和设计模式。你应该了解 UML。并且，你应该创建软件设计的轻量级模型。 …

事实上，TDD 是一门设计技术，但不是孤独的设计技术。所有的老设计规则和技能仍然适用。TDD 能够影响和增强它们。

针对他的有关“石器时代”的博文，Martin 探讨了“TDD 是否应该应用于每一行代码？”。答案还是否定的：

不。对于某些问题来说 TDD 是无益的。GUI 就是一个例子。 …

当然不仅仅是 GUI。摆弄（fiddling）的想法才是关键。如果你必须把代码摆弄到位，如果你必须摆弄一些方面以满足客户。如果存在一些不确定性只能通过快速的编辑——运行周期解决，那么 TDD 与其说是一种帮助，不如说是一种障碍。

管理的技巧在于认真的退耦（decoupling）。你需要确保识别出所有不需要摆弄的代码，然后把它们分成可以通过 TDD 编写的模块。确保摆弄的代码被隔离并降低到最少。

Martin 承认，事实上某些测试更适合稍后编写，他重申只有在必要时才需要这样做（当需要摆弄时）。最重要的原因在于“这种做法提高了每行代码和每个决定被测试的几率”，如果测试不首先编写，即使最训练有素的开发人员也会写出难以测试的代码。

Bob 大叔随后抛出了一个有趣的问题：“既然我们认可测试的必要性，为何会出现对测试优先的抵制？”。针对这个问题，他认为某些人不能增量的思考代码：

坦白说，我不知道（为何对测试优先的抵制如此强烈）。既然无论如何我们都要编写测试，很显然这不是一个生产力的问题。 或许某些人不希望编写测试打断工作流。是的，当你首先编写测试时，你不能编写一个完整的算法。你不得不随着一个个测试的添加来完成这个算法。可能某些人对这种方式不适应。

Martin 最后对一个常见说法给予了答复：“如果没有这么高的测试覆盖率，项目进度不是会更快吗？”首先，他承认对遗留环境（代码没有测试）采取高覆盖率的确需要长期的高投入。针对非遗留环境和遗留环境的新代码，他的答案则相反，在这种情况下，高度自动化的测试覆盖会提升你的速度。原因在于：

第一，你无需做太多调试。如果你已经测试了每一行代码你会怎么做？根据我的经验，调试时间完全不需要了。在去年 FitNesse 的紧张开发过程中，我几乎没有花时间调试。如果不得不把时间量化，那么可能是 5 小时或者更少。 第二，我绝不会无意中破坏代码。测试集会在数秒钟内发现这种意外！这让我无所畏惧。当你勇往直前时，你的步伐就会更快。

第三，我的测试都是系统如何工作的小例子。每当我忘记系统的某部分时，我就读一下测试例子。它们让我的进度很快赶了上来。

第四，我无需持续的与 bug 作斗争。即使我有几千个用户，我的 bug 列表很小。每周花在技术支持的时间不超过一小时，而且通常都是告诉用户如何从指南中找到解决办法。

请查看 Bob 的博客以获得更多细节和具体实例，同时拿出一点时间阅读一下大量的回复和注释中的箴言。

查看英文原文： Uncle Bob On The Applicability Of TDD