单元测试对我来说听起来很棒，但我不确定除非我可以说服其他人具有重大价值，否则我不应该花任何时间真正地学习它。我必须说服其他程序员，更重要的是，要让管理中的bean计数器相信，花在学习测试框架，编写测试，保持它们更新等上的所有额外时间都可以收回成本，然后付出一些。

有什么证明？有没有人实际上由两个独立的团队来开发相同的软件，一个使用单元测试，另一个不使用单元测试，并比较结果？我对此表示怀疑。我是否应该以“在Internet上查找它，每个人都在谈论它，所以它一定是正确的事情”来证明它的合理性？

在哪里有确凿的证据可以使外行信服单元测试值得努力？

是。这是一个链接在NCST的调查结果表明波比乔治和劳瑞·威廉姆斯和另一个由Nagappan等。我敢肯定还有更多。Williams博士有关测试的出版物可能为找到它们提供了一个很好的起点。

[编辑]上面的两篇论文特别提到了TDD，并表明采用TDD后初始开发时间增加了15-35％，但释放前缺陷减少了40-90％。如果您无法获得全文本版本，建议您使用Google学术搜索查看是否可以找到公开版本。

“我必须劝服其他程序员，更重要的是，要帮助管理中的bean计数器，所有花在学习测试框架，编写测试，保持它们更新等上的额外时间都将自己付出代价，然后再付出一些。 ”

为什么？

为什么不安静地，离散地这样做呢？您不必一次完成所有操作。您可以分小块来完成。

框架学习花费很少的时间。

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

没有单元测试，您所拥有的只是对软件的信心。通过一项单元测试，您仍然可以放心，并证明至少有一项测试通过了。

这就是全部。没有人需要知道您正在这样做。去做就对了。

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

您有什么保证您的代码正确？还是当团队中的某人更改func1（）时，它不会破坏假设X？如果没有单元测试使您保持“诚实”，我不确定您是否有足够的把握。

保持测试更新的概念很有趣。测试本身不必经常进行更改。我有3倍的测试代码相比，产品代码和测试代码已经改变非常小。但是，这是让我在晚上睡个好觉的原因，也是使我告诉客户我有信心可以在不破坏系统的情况下实现Y功能的事情。

也许在学术界有证据，但是我从来没有在商业世界的任何地方工作过，任何人都愿意为这种测试付费。但是我可以告诉您，它对我来说效果很好，花了很少的时间就习惯了测试框架，编写测试使我真正考虑了自己的要求和设计，远远超过了在团队中工作时所经历的时间。没有写测试。

这就是它的回报：1）您对代码有信心，2）您比以前更早发现问题。您没有质量检查人员说：“嘿，您没有麻烦检查xyz（）函数，对吗？ 他没有找到该bug，因为您一个月前就发现了。这对他，对您有好处，对公司有好处，对客户也有好处。

显然，这是轶事，但它为我带来了奇迹。不确定我可以为您提供电子表格，但是我的客户很满意，这就是最终目标。

我们有充分的证据表明，无需进行单元测试就可以编写糟糕的软件。我相信，甚至有证据表明单元测试中的软件太差劲了。但这不是重点。

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

即使这不是您的问题，但我想知道这是否真的是最简单的方法，可以回答错误的问题（并提供可能受到其他报告质疑的证据）。即使您找到了确凿的证据，也可能有人反对。

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

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

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

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

关于TDD的更多内容，不仅仅包括严格的单元测试，它还涉及通过测试驱动的开发实现质量改进： Nagaappan，E。Michael Maximilien，Thirumalesh Bhat和Laurie Williams 的四个工业团队论文的结果和经验。由Microsoft 经验软件工程与测量（ESM）组发布的论文，此处已提及。

该团队发现，TDD团队所产生的代码（在缺陷密度方面）比非TDD团队高出60％到90％。但是， TDD团队花费了15％到35％的时间才能完成他们的项目。

这是一个很棒的有趣的读物，讲述了一个人从内部改变公司的经历。不限于TDD。http://jamesshore.com/Change-Diary/请注意，他已经有一段时间没有说服“反击”了，而是采取了“游击战术”。

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

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

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

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

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

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

抽象：

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

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

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

好吧，有些大型公司要求您使用单元测试，但是如果您是小型公司，为什么要模仿大型公司？

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

我习惯了将程序设计和REPL放在首位，所以当我进行单元测试（每个功能一个测试）时，就像将REPL带回了很多可编译的语言一样。它把乐趣带回到了我编写的每一行代码中。我感觉到上帝了。我喜欢 我不需要报告就可以告诉我我开始更快地编写更好的代码。我的老板不需要报告就可以注意到，因为我们在做疯狂的事情，所以我们突然没有错过最后期限。我的老板不需要报告就可以注意到，由于编写非生产性代码这一非常奇怪的事情，“普通”错误的数量从（很多）下降到了几乎为零。

正如另一位发帖人所写，您不使用TDD进行测试（验证）。您编写它来捕获规范，单元（对象，模块，函数，类，服务器，集群）的工作行为。

在许多公司中，有很多失败和成功的故事，它们都转向了不同的软件开发模型。

每当我有新东西要写时，我就开始使用它。有句古话对我来说很难翻译成英语，但是：

从简单的事情开始，您不会注意到自己在做。训练马拉松时，首先要步行9米，然后跑步1米，然后重复。

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

编辑：例如，如前所述，“ 代码完整 ” 这本书报告了此类研究（第20.3段，“质量技术的相对有效性”）。但是咨询领域也有私人研究证明了这一点。

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

许多个月前，我刚毕业，从事大型VB6项目的工作，并有机会编写大量的存储过程代码。我正在编写的子系统中，它约占整个代码库的1/4-在50K左右的范围内，约有13,000 LOC。

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

从QA的统计数据来看，整个子系统上出现了大约40或50个缺陷，其中两个源自存储过程。这是每6,500行代码中的一个缺陷，而整个每1000-1,200。还请记住，大约VB6代码的2/3是用于错误处理和记录的样板代码，在所有过程中都是相同的。

无需花费过多的精力，就可以将缺陷率的改善至少提高一个数量级。