有统计数据证明，修复单元/集成测试中发现的 bug 的成本要比在活动系统上修复的成本低很多倍(它们是基于对数千个实际项目的监控)。

编辑 : 例如，正如所指出的，《 代码完成》一书报告了这类研究(第20.3段，“质量技术的相对有效性”)。但在咨询领域也有私人研究证明了这一点。

我们已经用确凿的证据证明，不进行单元测试就可以编写蹩脚的软件。我相信甚至有证据表明单元测试的软件很糟糕。但这不是重点。

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

尽管这不是你的问题，但我想知道这是不是最简单的方法来回答那些可能被问错的问题(并带来可能被其他报告质疑的证据)。即使你找到了确凿的证据，其他人也可能找到对你不利的确凿证据。

决定技术人员应该如何工作是财务人员的职责吗？他们在所有情况下都提供最便宜的工具，是因为他们认为你不需要更昂贵的工具吗？

这种争论要么基于信任(敏捷团队的基本价值观之一)而胜出，要么基于胜利方的角色力量而失败。即使 TDD 的支持者基于角色权力获胜，我也会认为他们失败了。

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

你有什么保证你的代码是正确的？或者当您的团队中的某人更改 fun1()时，它不会打破 X 假设？如果没有单元测试使您保持“诚实”，我不确定您是否有很大的把握。

保持测试更新的概念很有趣。测试本身并不经常需要改变。与生产代码相比，我得到了3倍的测试代码，而且测试代码对 非常的改动很小。然而，正是它让我晚上睡得安稳，也让我能够告诉客户，我有信心在不破坏系统的情况下实现 Y 功能。

也许在学术界是有证据的，但我从来没有在商业世界的任何地方工作过，有人会为这样的测试付费。然而，我可以告诉你，它对我来说工作得很好，很快就适应了测试框架，编写测试让我考虑我的需求和设计，远远超过我在没有编写测试的团队工作时所做的。

下面是它的回报: 1)你对你的代码有信心，2)你比其他方式更早地发现问题。你不会让 QA 人员说“嘿，你没有检查 xyz ()函数的边界吧?”？他找不到这个漏洞，因为 你一个月前就找到了。这对他有好处，对你有好处，对公司有好处，对顾客也有好处。

显然，这只是传闻，但对我来说却创造了奇迹。不确定我能否提供电子表格，但我的客户很高兴，这是最终目标。

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

对于我来说，多年前开始单元测试时(今天我们大多使用 行为模型) ，那是因为我不能控制一个应用程序中的所有路径。

我曾经习惯于底部第一个编程和一个 REPL，所以当我得到单元测试(每个函数一个测试)的时候，它就像把一个 REPL 带回到那些非常需要编译的语言中。 它把乐趣带回到我写的每一行代码中。 我感觉到了上帝。 我很喜欢。 我不需要一份报告来告诉我，我已经开始更快地编写更好的代码了。 我的老板不需要一份报告就能注意到这一点，因为我们在做一些疯狂的事情，突然之间我们从来没有错过最后期限。 我的老板不需要一份报告就可以注意到，由于编写非生产性代码这件非常奇怪的事情，“普通”bug 的数量从(许多)下降到几乎为零。

正如另一个海报已经写的，你不用 TDD 来测试(验证)。您编写它是为了捕获规范，捕获您的单元(对象、模块、函数、类、服务器、集群)工作的行为。

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

我只是在有新东西要写的时候才开始用它。 有句老话我很难翻译成英语，但是:

从简单的开始 你不会注意到你做了什么。 当进行马拉松训练时，从步行9米开始，然后跑1米 计价器，重复。

是的。这是 NCST 的 Bobby George 和 Laurie Williams 的研究的 链接和 Nagappan 等人的 另一个。肯定还有更多。威廉姆斯博士的 出版物测试可能提供了一个良好的起点，找到他们。

上面的两篇文章特别提到了 TDD，并且显示在采用 TDD 之后，初始开发时间增加了15-35% ，但是预发布缺陷减少了40-90% 。如果您无法获得全文版本，我建议使用 谷歌学者来查看是否可以找到公开可用的版本。

我必须说服其他程序员，更重要的是说服管理层的计算员，让他们相信所有额外的时间都花在了学习测试框架、编写测试、保持测试的更新等等。会为自己付出代价，甚至付出更多。”

为什么？

为什么不悄悄地，谨慎地做呢。你不必一次做完。你可以把它切成小块。

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

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

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

这就够了，没人需要知道你在做什么，做就是了。

这里有一个伟大的和有趣的阅读一个家伙改变他的公司从内部。它不仅限于 TDD。http://jamesshore.com/Change-Diary/注意到他很长一段时间没有说服“会计师”，而是采取了“游击战术”。

我确实有一组数据点，这些数据点来自于我在单元测试中获得的经验。

很久以前，我还是一个刚毕业的大型 VB6项目的研究生，有机会编写大量的存储过程代码。在我编写的子系统中，大约1/4的代码构成了整个代码库——大约50K 中有13000个 LOC。

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

质量保证(QA)的统计数据表明，整个子系统共产生约40或50个缺陷，其中 两个来源于存储过程。这是 每6500行代码中有一个缺陷对每1,000-1,200左右整个作品。还要记住，大约2/3的 VB6代码是用于错误处理和日志记录的样板代码，在所有过程中都是相同的。

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

除了严格的单元测试之外，还有更多关于 TDD 的内容，这里是 Nagappan、 E. Michael Maximilien、 Thirumalesh Bhat 和 Laurie Williams 撰写的 通过测试驱动开发实现质量改进: 四个行业团队的成果和经验论文的链接。微软 经验软件工程与度量(ESM)集团发表的论文，这里已经提到。

团队发现 TDD 团队产生的代码比非 TDD 团队产生的代码(在缺陷密度方面)好60% 到90% 。然而 TDD 团队花费了15% 到35% 的时间来完成他们的项目。

如果你也对反对单元测试的证据感兴趣，这里有一篇经过充分研究和深思熟虑的文章:

为什么大多数单元测试都是浪费

为了给这些答案添加更多的信息，有两个元分析资源可能有助于弄清楚学术和行业背景对生产力和质量的影响:

客座编辑介绍: TDD ー无畏编程的艺术[ 链接]

所有的研究人员似乎都同意 TDD 鼓励更好的任务集中 和测试覆盖率。仅仅是更多测试的事实并不一定 意味着软件质量会更好，但增加 尽管如此，程序员对测试设计的关注是令人鼓舞的 把测试看作是对大量潜在人群的抽样调查 行为，更多的测试意味着更彻底的样本。在某种程度上, 每个测试都能找到其他测试都找不到的重要问题 发现，这些测试是有用的，特别是如果你能廉价地运行它们。

表1. 选定的测试驱动实证研究的总结 发展: 行业参与者 *

表2. TDD 的若干实证研究摘要: 学术 参加者 *

测试驱动开发对外部质量和生产力的影响: 荟萃分析[ 链接]

摘要:

本文提供了一个系统的荟萃分析的27个研究 研究测试驱动开发对外界环境的影响 代码质量和生产率。

结果表明，总的来说，TDD 对质量的影响很小，但对生产力的影响很小甚至没有明显的影响。然而，亚组分析有吗 发现质量的提高和生产力的下降 与学术研究相比，工业研究的规模要大得多。 生产力下降更大的研究发现 TDD 和对照组在测试工作上的差异 质素方面亦有较大改善 在学术研究中发现，当考试努力的差异是 实质性的; 然而，无法得出关于 由于缺乏数据而进行的工业研究。

最后，影响 开发人员的经验和任务大小作为调节变量 调查，并统计显着的正相关是 在任务大小和改进的程度之间找到 质素。