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

阅读数:2057 2019 年 11 月 11 日 08:49

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

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

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

事件起因

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

评论

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