春争日,夏争时,扫码抽取夏日礼包!!! 了解详情
写点什么

“TDD 已死”之论战调查

  • 2014 年 6 月 10 日
  • 本文字数:2109 字

    阅读完需:约 7 分钟

测试驱动开发( 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 Bob Martin 在他的回复中说“如果你不做 __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


感谢杨赛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014 年 6 月 10 日 02:483312

评论

发布
暂无评论
发现更多内容

第八周作业

赵龙

设计过度有时比设计不足更可怕

菜根老谭

架构思维 过度设计 演化思维 设计不足

Week 08 学习总结

Jeremy

架构师训练营第八章作业

itrickzhang

扎克伯格:从程序员到福布斯全球首富,他经历了什么?

北柯

NameNode和SecondaryNameNode工作机制

奈学教育

NameNode

第八周作业

andy

极客大学

shell实现SSH自动登陆

阿呦,简笔话_Golden

面经手册 · 开篇《面试官都问我啥》

小傅哥

面试

世界上最狠的语言

十三

架构师训练营 - 第八周 - 学习总结

stardust20

行为型模式:迭代器模式解析

Seven七哥

Java 编程 程序员 设计模式 迭代器模式

一周信创舆情观察(7.20~7.26)

统小信uos

第八周总结

andy

极客大学

架构训练营第八周作业

张锐

保障服务稳定之服务限流

X先生

后端 架构设计 服务设计 限流算法

敏捷开发:影响地图工作坊的反思

华为云开发者社区

敏捷开发 业务线 需求管理 需求 华为云

英特尔®边缘软件中心重磅发布 一站式资源供给为应用开发创新赋能

最新动态

面试官问:如何设计一个安全的对外接口?

Java小咖秀

Java 面试 经验

架构师训练营第8周

大丁💸💵💴💶🚀🐟

产品、方案、生态三力齐发 英特尔驱动智能边缘价值迸发

最新动态

第八周学习总结

赵龙

Java开发Spark ELT实践(一)

团子粑粑

大数据 Apache Spark

天天用SpringBoot,它的自动装配你能说出来吗?

java金融

Java spring springboot 自动装配 EnableAutoConfiguration

Week 08 命题作业

Jeremy

架构师训练营第八章总结

itrickzhang

JVM详解之:汇编角度理解本地变量的生命周期

程序那些事

Java JVM 汇编 生命周期

架构师训练营第八周作业

sunnywhy

极客大学架构师训练营

你好,工作!

小天同学

工作 心态 自我思考

架构师训练营 -- 第八周作业

stardust20

域名凭什么能卖出亿元高价?

北柯

创业 互联网 域名解析

“TDD已死”之论战调查_文化 & 方法_Shane Hastie_InfoQ精选文章