unit testing的投资回报是否有确凿的证据？

unit testing对我来说听起来很棒，但是我不确定我应该花费什么时间真正学习它，除非我能说服其他人具有重要价值。 我必须说服其他程序员，更重要的是说服pipe理中的bean-counter，花在学习testing框架，编写testing，保持更新等等上的所有额外时间将会为自己付出代价，然后再付出一些代价。

有什么证据呢？ 有没有人实际上开发了两个独立的团队相同的软件，一个使用unit testing，另一个不是，并比较结果？ 我对此表示怀疑。 我只是为了certificate这一点：“在互联网上查看，大家都在谈论这个问题，所以一定是正确的做法”？

在哪里可以说服外行说单位testing是值得的？

Answer 1

是。 这是由Boby George和Laurie Williams在NCST和Nagappan等人研究的一个链接 。 我相信还有更多。 威廉斯博士关于testing的出版物可能为find他们提供一个很好的起点。

[编辑]以上两篇论文具体参考了TDD，采用TDD后的初始开发时间增加了15-35％，但是释放前的缺陷减less了40-90％。 如果您无法阅读全文，我build议您使用Google Scholar来查看是否可以find公开的版本。

Answer 2

“我必须帮助其他程序员，更重要的是pipe理中的bean-counter，花在学习testing框架，编写testing，保持更新等等上的额外时间，将会为自己付出代价，然后再付出一些代价。 “

为什么？

为什么不就这么静静地离散呢？ 你不必一次完成。 你可以用小小的东西做到这一点。

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

写一个testing，只有一个，花费很less的时间。

没有unit testing，你所拥有的只是对你的软件有一定的信心。 通过一次unit testing，您仍然有自信，并且certificate至less有一次testing通过。

这一切都需要。 没有人需要知道你在做什么。 去做就对了。

Answer 3

我采取了不同的方法：

你有什么保证，你的代码是正确的？ 或者，当你的团队中的某个人改变func1（）时，它不会破坏假设X？ 没有unit testing让你“诚实”，我不确定你有多大的保证。

保持testing更新的概念是有趣的。 testing本身并不经常改变。 与生产代码相比，我已经得到了3倍的testing代码，testing代码已经改变很less了。 但是，晚上让我睡得好，让我告诉客户我有信心可以在不破坏系统的情况下实现Yfunction。

也许在学术界有证据，但我从来没有在商业世界的任何地方工作过，任何人都会为此付出代价。 然而，我可以告诉你，它对我来说工作得很好，花了很less的时间来习惯testing框架，写作testing让我真正思考我的需求和devise，远远超过了我在开发团队写了没有testing。

这就是它自己付出的代价：1）你对自己的代码有信心，2）你比别人更早地发现问题。 你没有QA的人说：“嘿，你没有打扰边界 – 检查xyz（）函数，是吗？ 他一个月前找不到这个bug，这对于他，对你有好处，对公司有好处，对客户有好处。

显然这是一个轶事，但它为我创造了奇迹。 不知道我可以提供电子表格，但我的客户很高兴，这是最终目标。

Answer 4

我们已经certificate，有证据表明，可以在没有unit testing的情况下编写蹩脚的软件。 我相信甚至有unit testing的蹩脚软件的证据。 但这不是重点。

unit testing或testing驱动开发（TDD）是一种devise技术，而不是testing技术。 写入testing驱动的代码看起来完全不同于不是的代码。

即使这不是你的问题，我想知道这是否是最简单的方法，可以回答问题（并且带来可能会受到其他报告质疑的证据），这可能是错误的。 即使你发现你的案件的确凿证据 – 其他人可能会发现有力的证据。

确定技术人员应该如何工作是否是豆制品柜台的业务？ 他们是否提供所有情况下最便宜的工具，因为他们认为你不需要更昂贵的工具？

这个论点要么是基于信任（敏捷团队的基本价值之一），要么是基于获胜方的angular色权力而失败。 即使TDD支持者赢得了angular色权力，我也会把它算作是失败的。

Answer 5

关于TDD的更多信息要比严格的unit testing更重要，这里是通过testing驱动开发实现质量改进的一个环节： Nagappan，E. Michael Maximilien，Thirumalesh Bhat和Laurie Williams 四个工业团队论文的结果和经验 。 由微软Empirical Software Engineering and Measurement （ESM）小组发表的论文已经在此提及。

研究小组发现，TDD团队制作的代码比非TDD团队的代码要好（在缺陷密度方面）要高出60％到90％。 然而 TDD团队花费了15％到35％的时间来完成他们的项目。

Answer 6

这里是一个从内部改变他的公司的一个伟大和有趣的阅读。 它不限于TDD。 http://jamesshore.com/Change-Diary/请注意，他并没有说服“豆制品柜台”一段时间，而是采取了“游击战术”。;

Answer 7

那么，有一些大公司要求你使用unit testing，但如果你是一个小公司，为什么要模仿大的呢？

对于我来说，在多年前开始进行unit testing的时候，（现在我们主要使用行为模型）是因为我无法控制一个应用程序中的所有path。

我习惯于底层编程和一个REPL，所以当我得到unit testing（每个函数的一个testing）时，就像将REPL带回到编译非常多的语言。 它为我写的每一行代码带来了乐趣。 我感觉到了上帝。 我喜欢它。 我不需要一个报告来告诉我，我开始写更好的代码更快。 我的老板不需要报告，因为我们在哪里做疯狂的事情，我们突然间没有错过任何一个截止date。 我的老板不需要一个报告就可以注意到，由于编写非生产性代码的这个非常奇怪的事情，“简单”错误的数量从几乎减less到几乎为零。

正如另一个海报已经写了，你不使用TDD来testing（validation）。 你写它来捕捉规范，你的单元（对象，模块，函数，类，服务器，集群）的工作行为。

在许多公司中，有很多失败和成功案例转向开发软件的不同模式。

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

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

Answer 8

有统计数据表明，修复在单元/集成testing中发现的错误，比在现场系统上修复（它们基于监测数千个现实生活项目）成本低很多倍。

编辑 ：例如，正如所指出的那样，“ 代码完成 ”一书报告了这些研究（第20.3节“质量技术的相对有效性”）。 但在咨询领域也有一些私人研究也certificate了这一点。

Answer 9

如果你也对unit testing的证据感兴趣，这里有一个很好的研究和思考的文章：

为什么大多数unit testing是浪费James O Coplien（精益和敏捷专家）

Answer 10

我确实有一套数据点 – 从unit testing中销售我的经验。

许多月前，我是一个大型VB6项目的新gradle生，有机会写一大堆存储过程代码。 在我编写的子系统中，大约是整个代码库的四分之一，大概在5万左右，大约有13,000个LOC。

我为存储过程编写了一套unit testing，但是没有像Rational Robot这样的工具，unit testingVB6 UI代码并不是真的可行; 至less当时不是那个时候。

QA的统计数据显示，整个子系统存在40或50个缺陷，其中两个来源于存储过程。 这是每6500行代码中的一个缺陷 ，而整个代码中每1,000-1,200个代码有 1 个缺陷 。 请记住，大约2/3的VB6代码是用于error handling和日志logging的样板代码，在所有过程中都是相同的。

没有太多的手脚，你可以把unit testing的缺陷率至less提高一个数量级。

Answer 11

为了给这些答案增加更多的信息，有两个元分析资源可以帮助我们找出在学术和行业背景下的生产力和质量的影响：

嘉宾编辑简介：TDD – 无畏编程艺术[ 链接 ]

所有研究人员似乎都认为，TDD鼓励更好的工作重点和testing覆盖率。 事实上，更多的testing并不一定意味着软件质量会更好，但是程序员对testingdevise的关注却是令人鼓舞的。 如果我们把testing看作是抽取一大批潜在行为的样本，那么更多的testing就意味着一个更彻底的样本。 如果每个testing都能find一个其他人都找不到的重要问题，那么这个testing就很有用，特别是如果你能够廉价地运行它们的话。

表1.对testing驱动开发的选定实证研究的总结：行业参与者*

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

testing驱动开发对外部质量和生产力的影响：一个元分析[ 链接 ]

抽象：

本文提供了27项研究的系统荟萃分析，研究testing驱动开发（TDD）对外部代码质量和生产力的影响。

结果表明，总的来说，TDD对质量的影响很小，但对生产力的影响却很小或没有明显的影响。 然而，亚组分析发现，与工业研究相比，质量改进和生产率下降要大得多。 在TDD和对照组过程的testing努力差异显着的研究中发现生产力下降较大。 在学术研究中，当testing工作的差异很大时，质量也有了较大的提高; 然而，由于缺乏数据，没有得出关于工业研究的结论。

最后，研究了开发者经验和任务规模作为调节variables的影响，发现任务规模与质量改善幅度呈显着正相关。