写点什么

观点:测试驱动的开发从根本上是错误的

  • 2019-11-11
  • 本文字数:1416 字

    阅读完需:约 5 分钟

观点:测试驱动的开发从根本上是错误的

这听起来太绝对,但确实是这样。


事件起因

2008 年,我为 Windows 7 任务栏写了一个扩展插件,最后的应用程序非常小,只有几页代码。完成后,我接到指示,要为这个应用程序写单元测试,这么做只是为了能让经理检查打分。我拒绝了,因为这个项目实在太小了,根本不需要单元测试。而且,为了添加这些愚蠢的测试把应用程序拆成几个部分,意味着使本来已经通过了测试并准备发布的应用程序变得不稳定。


随着这次沟通逐渐无法进行,经理告诉了我一些话,即所谓的“测试驱动开发”,这时,我下决心要结束这场谈话,因为这是我第一次听到这样不合理的说辞:


当测试全部通过,你就完成了任务。


我遇见的每一个TDD(Test Driven Development)宣传者都会一字一句地重复上面这句话。

测试什么时候写?

当时的我已经有了 20 多年的软件开发经验,我第一次意识到明显的缺陷所在,编码前就写测试需要记住一点:在与敌人的接触中,没有任何战争计划能够幸存。我工作过的大部分地方都认为软件计划是在浪费时间,他们最多也就是走走流程。


在微软,我好几次因为在软件开发中做了周全的规划而受到惩罚,特别是在写威胁模型时。但是,我总是从需求功能规范开始规划工作,我拒绝了一些潜在客户,他们不愿意在编码前花时间做软件设计。


但是,即使是最周全的计划也会在编码实现后出现非预期的紧急事件,即便在若干小时内不会出现,也会在数天内出现。客户们的设计总是比他们认为的更加模糊不清,即使是我竭尽全力,也会有一开始想不到的事情发生。


所以,如果采用 TDD 架构,我就得不断地查看测试,审核所有测试项,确保它们满足我在项目里的新发现。而如果在工作结束时,或者快要结束时编写测试,测试项就会包含编码时所有的新发现。所以,这些都比在编码完成后写测试合理得多。


以下是我所看到的 TDD 流程:


  1. 编写 TDD 测试

  2. 开始编码

  3. 发现非预期的事件

  4. 重写测试

  5. 继续实现

  6. 返回步骤 3 重复、重复、重复……

  7. (实际上,要多于 150 条测试)所有的测试都通过

  8. 发送到 QA 专区


假设,QA 部门因为 TDD 而没有被全部解雇。注意上面第四项,在大型项目中,重写测试可能要出现几十次,而每次重新检查 TDD 的测试项都是 100%浪费时间


传统方式更好


  1. 开始编码

  2. 发现非预期事件并修复

  3. 编码完成,编写测试并运行

  4. 修复 Bug

  5. 发送到 QA 专区


这种方法,我在有了发现之后才编写测试,因此,测试只针对最终的设计而编写,只在以下情况发生时重新审核测试:


  • QA 阶段发现 bug

  • 添加新的功能

  • 发布后发现新的 bug

问题

这里存在的问题是 TDD 假设开发者自己写测试程序,这很不合理。我见过很多开发者认为项目非常稳固,但其他人却能在一分钟内就攻破它,这是为什么?


这是因为开发人员在设计时产生的盲点也同样会出现在测试中。


有谁会写一个比 Yes-No 消息框更复杂的功能,却又不运行它呢?在编码实现之前就编写测试,并不会解决这个问题。不管是在编码前写测试还是编码后写,总有些情况是开发人员预想不到的,这些情况倒不一定是“边缘情况”。每个人的工作都需要其他人根据需求和功能规范进行黑盒测试。

结论

很多开发者可能有这样的想法:在 TDD 中重新审查测试所浪费的时间会带来更多收入,项目周期也会增加 20%到 50%,这会让收入增加 20%到 50%。但是,我认为这很不道德。坦率地说,这也十分无聊。


阅读任何有关 TDD 的宣传材料,它们都会归结到测试本身的争论,没有人会反对它,它也从不谈及在编码之前写测试的理由是什么。


原文链接:https://hackernoon.com/test-driven-development-is-fundamentally-wrong-hor3z4d


2019-11-11 08:493368
用户头像
赵钰莹 极客邦科技 总编辑

发布了 882 篇内容, 共 645.0 次阅读, 收获喜欢 2679 次。

关注

评论 2 条评论

发布
用户头像
哈哈哈,其实我觉得做开发的肯定希望TDD啊,改需求你跟测试改去,我只满足测试用例就完事了。做测试的,尼玛产品改来改去的让我也改来改去的,我不同意!!!
2019-11-28 13:48
回复
用户头像
这种TDD已死的文章看过好几篇,正方,反方的说话我也度过好多,其中不乏kent beck这样的大牛,就这篇文章来说,作者一致再纠结先写测试还是生产代码写完后再写测试的问题,这说明其思维停留在测试和编码这两方面,对于生产代码的设计(API的设计,职责的划分等等,配置初始化构建和使用等等)却只字未提,这种纠结的心里和我编了10年代码(先生产后写测试代码)后的某个向测试驱动转变的时期很像,这是种再正常不过的感觉..直到你真正跨过那到坎才能体会好与不好,而不是浅尝辄止..然后尖叫..
2019-11-12 15:32
回复
没有更多了
发现更多内容

架构师训练营第三周”代码重构“作业

随秋

极客大学架构师训练营

生产环境全链路压测建设历程之七: 淘宝网2012年双十一库存超卖问题的本质

数列科技杨德华

第十二周作业(作业一)

Geek_83908e

架构师一期

第八周作业

孤星

命令行搜索神器fzf

Rayjun

Linux

数字人民币红包迎战“双十二” 六大行钱包全接入

CECBC

数字人民币

【第十二周】课后作业

云龙

架构之书:雄心与《C++语言的设计与演化》

lidaobing

c++ 架构

架构师训练营 2 期 - 第八周总结

Geek_no_one

极客大学架构师训练营

Codurance不太一样

sherlockq

架构师训练营第八周作业

丁乐洪

LeetCode题解:22. 括号生成,BFS,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

一只支持凡尔赛文学创作的摄影手机

脑极体

架构师系列9: 找出单向链表合并节点

桃花原记

架构师训练营 1 期第 12 周:数据应用(一)- 作业

piercebn

极客大学架构师训练营

《社会中的数据可视化》PDF免费下载

计算机与AI

数据可视化

2020的另一面:5G的斯普特尼克之年

脑极体

宝马区块链负责人:我们是如何让区块链技术与汽车产业结合的?

CECBC

大数据

架构师训练营 第八周作业

文江

性能优化练习

Mars

第十二周作业(作业二)

Geek_83908e

架构师一期

陪你手撕源码系列之 STL set 相关算法

herongwei

c++ 算法 set stl

FFmpeg使用基础(音视频开发入门)

赖猫

性能优化总结二

Mars

第八周总结

孤星

架构师训练营第 1 期 - 第 12 周课后练习

Anyou Liu

极客大学架构师训练营

可能会重塑未来移动支付市场的格局

CECBC

货币

玛雅公约软件系统开发|玛雅公约APP开发

系统开发

推进工业互联网和区块链创新发展

CECBC

区块链 互联网

架构师训练营第 1 期第 12 周学习总结

好吃不贵

极客大学架构师训练营

架构师训练营 2 期 - 第 8 周命题作业

Geek_no_one

极客大学架构师训练营

观点:测试驱动的开发从根本上是错误的_语言 & 开发_Chris Fox_InfoQ精选文章