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

Question

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

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

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

Answer 1

是。这是来自NCST的Boby George和Laurie Williams以及Nagappan等人的link研究的another。我相信还有更多。威廉姆斯博士publications进行测试可能是找到它们的良好起点。

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

Answer 2

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

为什么？

为什么不这样做，悄悄地和离散地。您不必一次完成所有操作。你可以用很小的碎片做到这一点。

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

编写一个测试，只需一个，只需要很少的时间。

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

这就是全部。没有人需要知道你在做什么。就这么做。

Answer 3

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

您对代码的正确性有何保证？或者当团队中的某个人改变func1（）时，它不会破坏假设X？如果没有单元测试让你“诚实”，我不确定你有多少保证。

保持测试更新的想法很有意思。测试本身通常不必改变。与生产代码相比，我有3倍的测试代码，并且测试代码已经非常改变了。然而，这让我能够在晚上睡得好，这让我能够告诉客户我有信心在不破坏系统的情况下实现Y功能。

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

以下是它为自己付出的代价：1）您对自己的代码充满信心; 2）您比其他情况更早地发现问题。你没有QA的人说“嘿，你没有打扰边界 - 检查xyz（）函数，是吗？他没有找到那个bug，因为你一个月前发现。这对他有好处，对你有好处，对公司有利，对客户有利。

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

Answer 4

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

单元测试或测试驱动开发（TDD）是一种设计技术，而不是测试技术。编写测试驱动的代码与非代码完全不同。

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

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

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

Answer 5

有关TDD的更多信息，而不是严格的单元测试，这里有Nagappan，E。Michael Maximilien，Thirumalesh Bhat和Laurie Williams撰写的Realizing quality improvement through test driven development: results and experiences of four industrial teams论文链接。由Microsoft Empirical Software Engineering and Measurement（ESM）小组发布的论文已在此处提及。

团队发现，TDD团队生成的代码比非TDD团队的代码要好60％到90％（就缺陷密度而言）。 然而 TDD团队花费了15％到35％的时间来完成他们的项目。

Answer 6

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

Answer 7

如果您对单元测试的证据感兴趣，这里有一篇经过深入研究和思考的文章：

Why Most Unit Testing is Waste By James O Coplien (lean and agile guru)

Answer 8

嗯，有些大公司要求你使用单元测试，但如果你是一家小公司，为什么要模仿大公司？

对我来说，多年前开始进行单元测试时（今天我们大多使用behavior模型），这是因为我无法控制一个应用程序中的所有路径。

我习惯于第一次编程和REPL，所以当我得到单元测试（每个函数的一个测试）时，就像把REPL带回那些非常多编译的语言。 它为我写的每一行代码带来了乐趣。 我觉得上帝。 我喜欢它。 我不需要报告告诉我，我开始更快地编写更好的代码。 我的老板不需要报告就会注意到，因为我们在做疯狂的事情，我们突然间没有错过截止日期。 我的老板不需要报告注意到“普通”错误的数量从（到很多）下降到接近零，因为编写非生产性代码非常奇怪。

正如另一张海报已经写过，你不使用TDD来测试（验证）。你编写它来捕获规范，你的单元（对象，模块，函数，类，服务器，集群）的工作行为。

在很多公司中转换到不同的软件开发模式有很多失败和成功的故事。

每当我有新东西写的时候，我就开始使用它了。 有一句老话对我来说有点难以翻译成英文但是：

  

从简单的事情开始   你没注意到你这样做了。       在参加马拉松训练时，首先步行9米跑1   米，重复。

Answer 9

只是为这些答案添加更多信息，有两个元分析资源可以帮助我们找出生产力和效率。对学术和行业背景的质量影响：

嘉宾编辑＆＃39;简介：TDD-无所畏惧编程艺术[link]

  

所有研究人员似乎都同意TDD鼓励更好地关注任务   和测试覆盖率。仅仅进行更多测试的事实并非必然   意味着软件质量会更好，但增加了   程序员对测试设计的关注仍然令人鼓舞。要是我们   将测试视为对非常大的潜力进行抽样   行为，更多的测试意味着更彻底的样本。在某种程度上   每个测试都可以找到其他人都无法解决的重要问题   发现，测试很有用，特别是如果你可以便宜地运行它们。

     

表1.选定的试验驱动的实证研究摘要   发展：行业参与者*

     

     

表2.选定的TDD实证研究摘要：学术研究   参与者*

     

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

摘要：

  

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

     

结果表明，一般而言，TDD对质量的影响很小，但对生产率几乎没有明显的影响。但是，亚组分析有   发现质量改进和生产力下降   与学术研究相比，工业研究中的规模要大得多。   在研究中发现了更大的生产力下降   TDD和对照组之间的测试工作量差异   过程很重要。质量也有了较大的提高   在学术研究中发现，当测试工作的差异是   大量的;但是，关于这个问题没有得出任何结论   由于缺乏数据而进行的工业研究。

     最后，影响力   开发人员经验和任务规模作为主持人变量   调查，并有统计学上显着的正相关   在任务规模和改进的幅度之间找到   质量。

Answer 10

有统计数据证明，修复单元/集成测试中发现的错误的成本比在实时系统上修复时要少很多倍（它们基于监视数千个实际项目）。

编辑：例如，正如所指出的，“Code Complete”一书报告了这些研究（第20.3段，“质量技术的相对有效性”）。但是咨询领域也有私人研究证明了这一点。

Answer 11

我确实有一套数据点 - 来自在单元测试中卖给我的经验。

很多以前，我是一名刚从事大型VB6项目的毕业生，有机会编写大量的存储过程代码。在我编写的子系统中，它占整个代码库的大约1/4 - 大约13,000个LOC，大约50K左右。

我为存储过程编写了一组单元测试，但是没有像Rational Robot这样的工具，单元测试VB6 UI代码是不可行的。至少它不是那时候的。

质量保证的统计数据显示，整个子系统中出现了大约40或50个缺陷，其中 2 来自存储过程。这是每6,500行代码中的一个缺陷与整个作品中每1,000-1,200左右的1个缺陷。还要记住，大约2/3的VB6代码是用于错误处理和记录的样板代码，在所有过程中都是相同的。

如果没有太多的手工操作，您可以将缺陷率的至少一个数量级的改进归因于单元测试。