Test-Driven Development?别逗了

Test-Driven Development?别逗了

这篇文章来源于Peter Sergeant在Write More Test 博客上的《Test-Driven Development? Give me a break…》,在原文和Reddit 上有很大反响。这篇文章里的很多观点在《TDD并不是看上去的那么美》和《再谈敏捷和TW咨询师》里都出现过(我个人觉得我的观点比其更全面一些)。就像我转的《Scrum为什么不行》 和《Bob大叔和Jim Coplien对TDD的论战》一样,从这些贴子我们可以看到——这是一个全世界的问题,并不是只有在中国才有的问题

很多敏粉都在说我在是喷敏捷,黑敏捷,向敏捷泼脏水,我只想对这些人说——你们这样的见解很肤浅也很敏感,你们根本就没有认识到——争论,反思和不同观点的意义,你也就无法了解你们所信仰的敏捷!你们只是在肤浅和盲目地信仰和教条敏捷中的许多名词、方法和标准答案罢了

——————————————正文开始——————————————

对于程序员来说有些事有非常危险的信号(red flag)。当我听到有人开始信仰Test-Driven Development 是 One True Programming Methodology(唯一正确的编程方法论),这就是危险信号(red flag),我开始假设你是一个劣等、没有经验的程序员,或是某些敏捷咨询师。

测试只是一个工具来帮助你,而不是用来证明谁比谁更虔诚,或是我的屌比你的要大,等这种愚蠢的行为。测试是用来让程序员得到有帮助的、更快的反馈,从而找到正确的路径,如果你搞坏一些事,其还可以用来给后人一些警告。这根本就不是一个神秘的有魔力的方法其可以让你的代码变得更好……

整个Test-Driven Development的概念是麻痹和信奉,从而让其成为你的人生观。相反的:Developer-Driven Testing,它给你和你的同事一些有用的工具来解决问题,来支持你自己,而不是那种以工具或方法为中心的让你假设其应该是那样的测试。

是不是在有些时候我们需要在写代码前写测试?当然是,比如,“修改已有的功能”,这会一个适用的场景,还有那些短小的和已定义完善的事物,或是对已被测试过的代码做一些改善。

但, 是不是你就应该需要总是要去先写测试?省省吧,别逗了。

这是极度白痴的行为,尤其是在设计,调查和开发的初期。让你的测试来接管你的代码(而不是影响那个模块的代码)和接管你的设计 这是一个巨大的失败,就是因为你写的那些测试范围太大太不靠谱。(陈皓注:我在《TDD并不是看上去的那么美》一文中说过测试案例的测试范围的问题,敏捷社区除了对我进行人身攻击外从未对此做过正面回答。)

在写代码前写测试案例在一些场景下的确很不错。然后,Test Driven Development,被敏捷专家或是其它各种五花八门的江湖骗子像神给凡人宣扬一样,这就是欺骗大众。

行动在想法之下,于是测试必需先行(所有我已看到的,所有我正在看到的都表明这是TDD的中心思想—— 你写了测试,然后你再写代码并通过测试),于是测试成为了最有用的活动并可以帮助程序员。这是错的。

就算你在一开始要写一些测试案例,但只要你想让这些测试案例更有意义,那么,你要么得让这些测试案例的测试范围更小更底层更精确,要么你就得在整个软件快要写完的时候再去写测试,要不然你就得欺骗或是篡改测试案例。在为数不多的情形下,前者是正确的——测试围绕于bug,或是小的,定义地很好的功能碎片(陈皓注:我个人理解为单元测试是目前最有效的))

把测试变成整个活动的中心因为其对程序员有用?真牛逼。老实说,控制程序员的工作流程只可能得出一条无比正确的答案——荒谬可笑。

测试帮助程序员,是因为其可以帮程序员组织自动化测试,所以才帮了程序员,而不是cargo-cult(货物崇拜,参看《各种流行的编程方法》中的cargo-cult编程)——信仰一种工作流程并让所有的人或事来适应于他。

先写测试这种方法只会在“Developer Driven Testing”(程序员自己驱动的测试)下可行——关注于选取一个正确的方法让程序员更有生产力。生成一堆测试的规则并说这是唯一的真理是不正确的。

一些讨论和想法(在此贴发出数小时后)…

当我这篇博文发出几个小时后,其被转到了别的地方并引发了一些讨论。

在 Hacker News 上,有人说我提出了很多很不错的问题,并且那是真正的有理有据的观点。我在用用户名叫peteretep 的回复了一些。

在 Reddit 上的争论更多更强。那里有很多的人觉得需要写自动化测试。并且这篇博文被大家演变成拥护测试和可实践的建议,我觉得我是误传达了我的想法,我觉得软件测试是非常重要的,而不是根据哪个方法论进行的教条主义!

——————————————正文结束——————————————

我在Reddit上看到了下面的事,我也作些评论。

  • 大家在讨论很多很多的技术细节,比如如何测试私有方法,如何测试inner class,甚至还有代码。我太喜欢了,这才是真正的讨论,而不是像酷壳这边那些敏粉们说人而不说事的讨论,那些所谓的敏捷咨询师的话里连一点技术细节都没有
  • 并且也有人说TDD可以让你去Design,但随后就有人说,正真的Design就是Design,而不是hack 测试来强行让你Design。后面有了附和到——有很多思想意识想用流程来代替思考,软件开发就是需要在某中上下文下去思考,而不是使用某种机制来让你思考
  • 我看了两极分化的大量的争论,这是我最喜欢看到事。世界就是因为有不同的观点而美好。有反对才有争论,有争论才有思考,这才是进步的源泉,而不是统一认识,形成标准。而对于那些党同伐异的,一听到有反对声就激动就要打压的敏粉来说,我只能认为他们的人生观世界观扭曲得就像朝鲜那样。
(全文完)


关注CoolShell微信公众账号和微信小程序

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (12 人打了分,平均分: 4.00 )
Loading...

Test-Driven Development?别逗了》的相关评论

  1. 关于TDD,我不是站在开发角度和测试角度,而是站在项目管理。
    理由很简单,我管谁要进度,谁就应该推动项目。之前我尝试过管开发要进度情况,但是非常不理想,有近30%以上的开发人员进度是不准确的,而且有时偏差还非常大。因此我考虑从测试要进度,情况很好,测试人员还是很忠实的将测试情况汇报给我。
    因此我觉得应该让测试人员尽快进入,至少不能比开发进来的晚,这样我才能了解真实进度情况。在加上每日构建,可以满足我对每天进度的跟踪。
    当然仅仅这样也不能说就是TDD,我觉得不教条才是学习的真谛。毕竟TDD是一种思想,我们是根据这个思想来转成执行的方法。就像学习佛法,喝酒吃肉和素鸡素鸭都是佛法。

发表评论

电子邮件地址不会被公开。 必填项已用*标注