本文转载至：http://www.infoq.com/cn/news/2014/06/tdd-dead-controversy/

测试驱动开发（TDD）是极限编程（XP）的核心实践之一（尽管该思想要比XP早数十年之久），并且它也被许多人认为是敏捷软件开发能够交付高质量软件的关键之一。

最近Ruby on Rails的作者、Basecamp的创始人DHH（David Heinemeier Hansson）在Railsconf 2014发表了开幕主题演讲（视频请见这里）。尽管TDD通常都被贯彻执行，DHH却在他的演讲中对TDD的价值进行了质疑和否定。

他之后又写了“TDD已死-测试永生”和“测试引起的设计伤害”这两篇文章来对这一主题进行了扩展。

Brian Oken对DHH的讲话和文章进行了总结：

• 许多推动TDD的开发人员会让你觉得：如果你不使用TDD的话，你的代码就是肮脏的。
• 由单元测试开始驱动你的设计并不是一个好的主意。
• TDD的概念“测试必须够快”是目光短浅的。
• 对TDD的依赖会导致彻底忘记系统测试。
• 关注并且只关注单元模块并不能有助于创建一套完美的系统。
• 100%的覆盖率是愚蠢的。
• 程序员希望软件是一门科学，可是它并不是。它更像是创造性的写作活动。
• 优秀的软件并不像工程学那样。
• 它更像写作。清楚简洁的写作要优于复杂晦涩的写作。
• 清晰是有好处的，好到应该将清晰性作为第一目标，而非测试覆盖度或者测试速度。
• 成为一名优秀的开发人员就像成为一名优秀的作家一样困难。
• 就像写作一样，成为优秀的程序员的办法就是以清晰为目标从而大量编写软件、大量阅读软件。

这引起了社区里广泛的反应（见推特标签#tddisdead），这些反应从“当然啦”到“这种说法太愚蠢了”都兼而有之（这里面的每个观点都可以划分到这两种中的一种）。

许多反馈都聚焦于在实践中应用TDD的必要性。

Uncle BobMartin在他的回复中说“如果你不做TDD或者其他像TDD一样有效的工作，那么你就应该会感觉不舒服”。他继续写道：

我们为什么要做TDD呢?我们有着一个最主要的理由以及一些次要的理由。这些次要的理由如下：

1. 我们可以花费更少的时间来进行调试。
2. 这些测试能够充当系统最底层的文档，它们精准、确切并且毫无歧义。
3. 编写TDD的测试首先需要解耦，而其他测试策略则不需要这么做，并且我们认为这种解耦是很有益的。

以上就是TDD的附带益处，并且是值得商榷的。然而，有一个好处在满足某些特定条件的情况下是毫无争议的：

• 如果你拥有一套你足够信任的测试套件，以至于你愿意系统在仅仅通过了那些测试的情况下进行部署，并且如果测试套件能够在几秒钟或者几分钟内执行完，那么你可以快速、轻易地清理代码而不必有所害怕。

Martin Fowler主持并记录了一系列他与DHH、Kent Beck（其最初的回答见这里）的聚会谈话，这些谈话探讨了TDD的使用以及它对软件设计的影响。

到现在为止，这个聚会已经组织了四次，而下一次的聚会是安排在6月4号，这将会是一个回答来自公众的问题的问答活动。

他将到目前为止的这些谈话进行了总结，内容如下：

1） 我们讨论了我们的不同经历：包括所采用的TDD流程、TDD以及自测试代码的那些经常让人困惑的方式。

2） David感觉使用TDD会导致类似于hexagonal rails这样的架构方式，hexagonal rails是一种测试引起的设计伤害，这是由于过度的间接关系造成的复杂性导致的。Kent则认为这更多是与设计决策的质量有关而与TDD的关系并不那么大。

3） 我们讨论了在编程过程中获取反馈的各种方式以及QA在给开发人员提供反馈过程中所起的作用。

4） 我们讨论了测试以及TDD的一些缺点：你有可能执行了过多的测试吗?团队对测试的重视程度高于对功能代码的重视程度会有问题吗？

Gergely Brautigam在一篇标题为“TDD已死——并不是事实”的文章中说道：

TDD并没有死。很明显，既然它有这么这么多的支持者，它怎么可能会死呢?这就像在问，设计模式死了吗？或者功能性自动化死了吗？或者奥利奥饼干死了吗？

不，它并没有死。而且它在将来任何时候都不会死亡。它将来可能会变成其他一些新的事物、甚至是一些更好的事物，但是它永远不会死亡。所以让我们跳过这一部分吧。

他进而在不同层次上讨论了测试的重要性并讨论了许多软件团队中测试做的不好的一些常见原因。他提到缺乏对质量的关注是一种很普遍的看法，并提到许多开发人员所经受的时间压力是他们只编写代码而不构建测试的最常见的原因。

他总结道：

这是我这10年来对软件测试领域的个人看法、经验和观察结果。至少要从一个不那么健壮的框架以及一些前期测试来进行启动，这从长远来看会对你有所帮助。至少编写一两条验收测试将会有助于你更好地理解业务逻辑。编写一两条单元测试将会帮助你更好地理解你的逻辑。我并没有说要将那些该死的测试全部都写下来，我能够理解你们是不会想要这样做的，但是看在质量的面子上，至少要编写一些。

Gil Zilberfeld提出了一个观点，旨在遵循敏捷宣言中的建议：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。

我们的探寻还尚未结束。TDD只是我们在这一历程中所寻找到的其中一种，还存在其他方式供我们去继续寻找。

查看英文原文：Examining the 'TDD is Dead' Controversy

感谢杨赛对本文的审校。