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

单元测试对我来说听起来很棒，但我不确定我是否应该花时间真正学习它，除非我能说服其他人它具有重要的价值。我必须说服其他程序员，更重要的是，管理层的bean计数器，所有额外的时间都花在学习测试框架、编写测试、保持更新上，等等。。会自己买单的，还有一些

有什么证据？有没有人用两个独立的团队开发了相同的软件，一个使用单元测试，另一个不使用，并比较了结果？我对此表示怀疑。我是不是应该用“在网上查一下，每个人都在谈论它，所以它一定是正确的事情”来为它辩护

---

有什么确凿的证据可以让外行相信单元测试值得付出努力？

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

---

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

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

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

尽管这不是你的问题，但我想知道这是否真的是最简单的方法来回答可能被问错的问题（并带来可能被其他报告质疑的证据）。即使你为你的案件找到了确凿的证据，其他人也可能会找到确凿的证据

---

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

---

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

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

你有什么保证你的代码是正确的？或者当团队中有人更改func1（）时，它不会打破假设X？如果没有单元测试让你“诚实”，我不确定你有多大把握

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

也许在学术界有证据，但我从未在商业世界的任何地方工作过，那里有人愿意为这样的测试付费。但是，我可以告诉你，它对我来说非常有效，几乎不需要花时间就习惯了测试框架，编写测试让我真正思考了我的需求和设计，远远超过了我在没有编写测试的团队中工作时的思考

这就是它的好处：1）您对代码有信心，2）您比其他情况更早发现问题。你不会让QA人员说“嘿，你没有费心检查xyz（）函数吧？他没有找到那个bug，因为你一个月前就发现了。这对他、你、公司和客户都有好处

---

很明显，这是一个轶事，但它对我产生了奇迹。我不确定我是否能提供给你电子表格，但我的客户很高兴，这是最终目标。

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

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

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

正如另一张海报所写的那样，您不需要使用TDD来测试（验证）。您编写TDD是为了捕获规范，即您的单元（对象、模块、函数、类、服务器、集群）的工作行为

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

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

从这么简单的事情开始 你没有注意到你这么做了。 马拉松训练时，先步行9米，然后跑1米 米，重复

是的。这是NCST的乔治和劳里·威廉姆斯（Boby George and Laurie Williams）和纳加潘（Nagappan）等人的一项研究的结果。我相信还有更多。威廉姆斯博士的测试可能为找到它们提供了一个很好的起点

[编辑]上述两篇论文特别提到了TDD，显示了15-35%