这些话来自于我们的软件领袖Jim Coplien—上世纪九十年代最流行的几本C++著作的作者。原话是这样的:
严格的按照YAGNI原则的驱动测试开发(TDD)会导致敏捷开发3次迭代结构的坍塌。
看到反TDD运动已经形成了一定的气候,真是让人感到非常的振奋,我特别喜欢Jim和Bob Martin 之间的争论,Bob Martin,这出了名的TDD极端主义者,认为任何一个程序员,只要所写的任何一行代码没有使用TDD,就不是一个专业的程序员。
Jim 和 Bob 最近的一次非常有趣的辩论,你可以在InfoQ找到他们的辩论记录。我很敬佩Jim在面对Bob时表现出来的礼貌和克制,因为当你的观点和Bob不一致时,他的言论永远都让你难以忍受。
TDD已经让我纠结了很久,你可以从InfoQ上发布的我的一场被叫做Designing for Testability的演讲,或从我最近和Hani Suleiman 一起合著的书里看到我对TDD的某些效果的质疑、甚至是反对。
我已经说过,别指望我会跟Bob Martin 唱对台戏。我绝对没有意思说你要永远别使用TDD,但我相信,TDD所带来的好处被过度的夸大,软件社区的人需要明白,TDD只是一种工具,对于一种工具,并不是所有的情形下都会好用。我特别不喜欢TDD极端主义者们的四处鼓噪、妄图使那些没有使用TDD的程序员感到沮丧,或使他们认为他们现在开发软件所使用的方式有什么不对。
如果让我说,我感觉大多数的TDD极端主义者在各种会议上说的太多太久了,已经不用动脑子就能举例写出一堆的用来计算保龄球得分的类和代码程序。而这些卡通式的小程序很容易,它们让TDD很风光。但是,当这些听众离开会场后挠着头纳闷如何让这种技术应用到自己的真实工作中时,你不要吃惊。如果你使用TDD去开发手机应用程序或去跟需要处理遍布3三大洲的上百万的两阶段提交事务的主框架进行交互的程序时,你算是撞上头彩了。
我不知道你的感觉如何,反正我是有点厌倦了软件社区里的这种危言耸听—无论它是来自TDD狂热分子还是来自那些声称绝不招聘不使用Mac做开发的人的人。
当需要进行测试时,我信守下面的经验主义的做法:
- “先测试”还是“后测试”并不重要,只要你是在测试。
- 在你的开发过程中尽可能早的考虑测试。
- 不要让某个框框限制了你的行动。例如,不要轻信那些人告诉你的、要写出“尽可能简单的能够运行的程序”—也就是所谓的YAGNI—的话。如果你的经验告诉你,未来你会用到这个额外的类—虽然现在用不着,你应该相信你的判断,加上这个类。
- 记住,功能测试是真正对用户有意义的测试。单元测试只是为你—开发者—服务的。属于奢侈品。如果你有时间去写单元测试,那最好了:当你的程序出现问题时,它们能帮助你省去很多时间。但如果你没有时间,你要确保功能测试能覆盖到你的产品里用户所期望的所有功能点。
- 如果你没有做驱动测试开发,不要有任何的不安。有太多的因素都能导致这种开发方法在众多的项目和个人开发习惯中水土不服(有很多因素那些TDD极端主义者们永远都不会提)。
不要让那些极端主义者把测试搞得痛苦不堪,如果你能运用自己的判断来实践它们,这将会成为你职业表现在最有价值的品行。
测试肯定是个问题
“先测试”还是“后测试”并不重要,只要你是在测试。
实用主义、经验主义都认为条条大路通罗马,只要满足需求就行。
但是毕竟软件开发一直都还没有“一定成功”的方法,
所以有探索产生的新规则和新技术,我认为也应该抱着开放的态度去观察。
反对的是极端主义唯TDD为上的做法,并不反对TDD的思想。
时间充裕的时候,你需要这些,说服客户增加人月,多赚钱。
TDD是一种制度。和现代的管理制度一样,是建立在对人的不信任,消极懒惰,主功能动性底下的基础上的。
Note:
“Jim 和 Bob 最近的一次非常有趣的辩论” — it was 3 years ago.
TDD与敏捷思想是矛盾的,TDD是一种比瀑布还瀑布的僵化开发方法,只在需求极稳定和简单的场景适用。
1.测试驱动不是先有测试,后有代码,而是工单的完成以通过测试为标准,
测试组件的开发和项目代码的开发是独立进行,相互没有耦合的不同工序,
测试组件的工作量远远低于产品生产的工作量,并且可重用度更高,
所以它们总是领先完成,而这不能就认为是”先有测试,后有代码”;
2.测试驱动开发和敏捷生产没有矛盾,而恰恰是敏捷生产的重要手段,
敏捷生产或者敏捷制造是指:先进生产方式的统称,
只要一个组织的生产手段领先于竞争对手,我们就说这些手段是敏捷的,
那些动辄就把结对编程,站立会议挂在嘴边的人根本就不懂敏捷生产,
先进的人力资源管理策略和生产工具都是敏捷生产的核心内容,
但是人力资源策略不能像高度自动化的生产工具那样为生产力效率带来几何积数级的提高
测试从根本上就是错的,证明才是对的
完全同意 缪军 的说法。测试驱动不单单是先写测试再写代码,而是先以产品的specification去形成integration tests / functional tests, then it’s unit tests etc..,从red, green, refactor种一步一步完成产品的功能。这样的开发更natural. 并不是说不TDD的程序员就不好,而是说TDD这个这么好的工具可以让程序员更轻松的写出把用户需求转成产品功能的代码。
感觉TDD是给外包公司用的。
测试设计和测试代码迭代太浪费时间了。测试代码本身的正确性和完整性怎么保证?