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

发表于:2019-11-12 11:25

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:夏夜译    来源:infoQ

  这听起来太绝对,但确实是这样。
  观点:测试驱动的开发从根本上是错误的
  事件起因
  2008 年,我为 Windows 7 任务栏写了一个扩展插件,最后的应用程序非常小,只有几页代码。完成后,我接到指示,要为这个应用程序写单元测试,这么做只是为了能让经理检查打分。我拒绝了,因为这个项目实在太小了,根本不需要单元测试。而且,为了添加这些愚蠢的测试把应用程序拆成几个部分,意味着使本来已经通过了测试并准备发布的应用程序变得不稳定。
  随着这次沟通逐渐无法进行,经理告诉了我一些话,即所谓的“测试驱动开发”,这时,我下决心要结束这场谈话,因为这是我第一次听到这样不合理的说辞:
  当测试全部通过,你就完成了任务。
  我遇见的每一个 TDD(Test Driven Development)宣传者都会一字一句地重复上面这句话。
  测试什么时候写?
  当时的我已经有了 20 多年的软件开发经验,我第一次意识到明显的缺陷所在,编码前就写测试需要记住一点:在与敌人的接触中,没有任何战争计划能够幸存。我工作过的大部分地方都认为软件计划是在浪费时间,他们最多也就是走走流程。
  在微软,我好几次因为在软件开发中做了周全的规划而受到惩罚,特别是在写威胁模型时。但是,我总是从需求和功能规范开始规划工作,我拒绝了一些潜在客户,他们不愿意在编码前花时间做软件设计。
  但是,即使是最周全的计划也会在编码实现后出现非预期的紧急事件,即便在若干小时内不会出现,也会在数天内出现。客户们的设计总是比他们认为的更加模糊不清,即使是我竭尽全力,也会有一开始想不到的事情发生。
  所以,如果采用 TDD 架构,我就得不断地查看测试,审核所有测试项,确保它们满足我在项目里的新发现。而如果在工作结束时,或者快要结束时编写测试,测试项就会包含编码时所有的新发现。所以,这些都比在编码完成后写测试合理得多。
  以下是我所看到的 TDD 流程:
  编写 TDD 测试
  开始编码
  发现非预期的事件
  重写测试
  继续实现
  返回步骤 3 重复、重复、重复……
  (实际上,要多于 150 条测试)所有的测试都通过
  发送到 QA 专区
  假设,QA 部门因为 TDD 而没有被全部解雇。注意上面第四项,在大型项目中,重写测试可能要出现几十次,而每次重新检查 TDD 的测试项都是100% 浪费时间。
  传统方式更好
  开始编码
  发现非预期事件并修复
  编码完成,编写测试并运行
  修复 Bug
  发送到 QA 专区
  这种方法,我在有了发现之后才编写测试,因此,测试只针对最终的设计而编写,只在以下情况发生时重新审核测试:
  QA 阶段发现 bug
  添加新的功能
  发布后发现新的 bug
  问题
  这里存在的问题是 TDD 假设开发者自己写测试程序,这很不合理。我见过很多开发者认为项目非常稳固,但其他人却能在一分钟内就攻破它,这是为什么?
  这是因为开发人员在设计时产生的盲点也同样会出现在测试中。
  有谁会写一个比 Yes-No 消息框更复杂的功能,却又不运行它呢?在编码实现之前就编写测试,并不会解决这个问题。不管是在编码前写测试还是编码后写,总有些情况是开发人员预想不到的,这些情况倒不一定是“边缘情况”。每个人的工作都需要其他人根据需求和功能规范进行黑盒测试
  结论
  很多开发者可能有这样的想法:在 TDD 中重新审查测试所浪费的时间会带来更多收入,项目周期也会增加 20% 到 50%,这会让收入增加 20% 到 50%。但是,我认为这很不道德。坦率地说,这也十分无聊。
  阅读任何有关 TDD 的宣传材料,它们都会归结到测试本身的争论,没有人会反对它,它也从不谈及在编码之前写测试的理由是什么。

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号