是否有确凿证据证明单元测试的投资回报率？

Question

单元测试对我来说听起来很棒,但我不确定我是否应该花时间真正学习它,除非我能说服其他人具有重要价值.我必须说服其他程序员,更重要的是说服管理中的bean计数器,所有额外的时间花在学习测试框架,编写测试,保持更新等等......将为自己付出代价,然后是一些.

有什么证据？有没有人真正用两个独立的团队开发相同的软件,一个使用单元测试而另一个没有,并比较结果？我对此表示怀疑.我只是应该证明这一点,"在互联网上查找,每个人都在谈论它,所以它一定是正确的做法"？

哪些证据可以说服外行人员单位测试值得付出努力？

Answer 1

是.这是Boby George和Laurie Williams在NCST和另一个由Nagappan等人进行的研究的链接.我相信还有更多.威廉姆斯博士关于测试的出版物可能为找到它们提供了良好的起点.

[编辑]上述两篇论文专门参考TDD,采用TDD后初始开发时间增加15-35%,但预发布缺陷减少40-90%.如果您无法获得全文版本,建议您使用Google学术搜索查看是否可以找到公开版本.

Answer 2

"我必须为其他程序员提供服务,更重要的是,管理中的bean计数器,学习测试框架,编写测试,保持更新等所有额外时间......将为自己付出代价,然后是一些. "

为什么？

为什么不这样做,安静而离散地做.您不必一次完成所有操作.你可以用很小的碎片做到这一点.

框架学习只需要很少的时间.

编写一个测试,只需一个,只需要很少的时间.

如果没有单元测试,您所拥有的只是对您的软件有信心.通过一次单元测试,您仍然有信心,并且证明至少有一次测试通过.

这就是全部.没有人需要知道你在做什么.去做就对了.

Answer 3

我对此采取了不同的方法:

你有什么保证你的代码是正确的？或者当团队中的某个人改变func1()时,它不会破坏假设X？没有单元测试让你'诚实',我不确定你有多少保证.

保持测试更新的想法很有意思.测试本身通常不必改变.我有3倍相比,生产代码的测试代码,测试代码已经变化非常小.然而,这是让我晚上睡得好的原因,也是让我告诉客户我有信心可以在不破坏系统的情况下实现Y功能的东西.

也许在学术界有证据,但我从未在商业世界的任何地方工作,任何人都会为这样的考试买单.但是,我可以告诉你,它对我来说效果很好,花了很少时间习惯于测试框架,编写测试让我真正考虑了我的要求和设计,远远超过我在团队工作时做过的事情.没有写任何测试.

这是它为自己付出的代价:1)你对你的代码有信心; 2)你比其他方式更早地发现问题.你没有QA的家伙说"嘿,你没有打扰边界 - 检查xyz()函数,对吗？ 他没有找到那个bug,因为你在一个月前发现它.这对于他,对你有好处,对公司有利,对客户有利.

显然,这是轶事,但它为我创造了奇迹.我不确定我能为您提供电子表格,但我的客户很满意,这是最终目标.

Answer 4

我们已经用坚实的证据证明,没有单元测试就可以编写糟糕的软件.我相信甚至有证据证明单元测试的软件很糟糕.但这不是重点.

单元测试或测试驱动开发(TDD)是一种设计技术,而不是测试技术.编写测试驱动的代码看起来与不代码的代码完全不同.

尽管这不是你的问题,但我想知道这是否真的是最简单的方法,可以回答问题(并提出可能受到其他报告挑战的证据).即使您找到了有关您案件的确凿证据 - 其他人也可能会找到反对的证据.

豆类计数器的业务是确定技术人员应该如何工作的吗？他们是否提供所有情况下最便宜的工具,因为他们认为您不需要更昂贵的工具？

这个论点要么基于信任(敏捷团队的基本价值之一)而赢得,要么基于获胜方的角色力量而失败.即使TDD支持者基于角色力量而获胜,我也会将其视为失败.

Answer 5

如果您还对反对单元测试的证据感兴趣，请阅读以下经过深思熟虑的文章：

为什么大多数单元测试都是浪费？James O Coplien（精益敏捷的专家）

Answer 6

更多关于TDD而不是严格的单元测试,这里是通过测试驱动开发实现质量改进的链接:由Nagappan,E.Michael Maximilien,Thirumalesh Bhat和Laurie Williams撰写的四个工业团队论文的结果和经验.由Microsoft 经验软件工程与测量(ESM)小组发布的论文已在此处提及.

该团队发现,TDD团队生成的代码比非TDD团队的代码要好60%到90%(就缺陷密度而言).然而, TDD团队花费了15%到35%的时间来完成他们的项目.

Answer 7

这是一个伟大而有趣的读物,一个人从内部改变他的公司.它不仅限于TDD.http://jamesshore.com/Change-Diary/请注意,他没有说服"豆专柜"很长一段时间,而是做了"游击战术".

Answer 8

只是为了向这些答案添加更多信息，有两种荟萃分析资源可以帮助弄清生产率和质量对学术和行业背景的影响：

客座编辑介绍：TDD —无所畏惧的编程艺术[ link ]

所有研究人员似乎都同意TDD鼓励更好地专注于任务和测试覆盖范围。仅仅是更多测试的事实并不一定意味着软件质量会更好，但是程序员对测试设计的更多关注仍然令人鼓舞。如果我们将测试视为对大量潜在行为的抽样，那么更多的测试意味着更彻底的采样。在某种程度上，每个测试都能找到其他人都找不到的重要问题，因此这些测试很有用，特别是如果您可以廉价地运行它们。

表1.测试驱动开发的一些经验研究摘要：行业参与者*

表2. TDD的一些经验研究摘要：学术参与者*

测试驱动开发对外部质量和生产率的影响：一项荟萃分析[ link ]

抽象：

本文对27项研究进行了系统的荟萃分析，这些研究调查了测试驱动开发（TDD）对外部代码质量和生产率的影响。

结果表明，总体而言，TDD对质量的积极影响较小，但对生产率的影响却很小甚至没有。但是，亚组分析发现，与学术研究相比，工业研究的质量提高和生产率下降都更大。在TDD和对照组过程之间的测试工作量差异显着的研究中发现生产率下降幅度更大。当测试工作的差异很大时，在学术研究中也发现质量有较大提高。然而，由于缺乏数据，无法得出有关工业研究的结论。

最后，研究了开发人员经验和任务大小作为主持人变量的影响，发现任务大小与质量改进幅度之间存在统计学上的显着正相关。