问单元测试的ROI有确凿的证据吗？

EN

是。这是NCST的Boby George和Laurie Williams的一项研究的link，以及Nagappan等人的another。我敢肯定还有更多。威廉姆斯publications博士的测试可能为找到他们提供了一个很好的起点。

编辑上面两篇专门引用TDD的论文，显示采用TDD后初始开发时间增加了15-35%，但预发布缺陷减少了40%-90%。如果你不能获得全文版本，我建议你使用Google Scholar，看看你是否可以找到一个公开的版本。

“我必须帮助其他程序员，更重要的是，管理中的计时器，所有花在学习测试框架、编写测试、保持更新等方面的额外时间都会有回报，甚至更多。”

为什么？

为什么不悄悄地、谨慎地去做呢？你不需要一次做完所有的事情。你可以用很小的片段来做这件事。

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

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

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

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

我们已经用确凿的证据证明，可以在没有单元测试的情况下编写糟糕的软件。我相信甚至有证据表明单元测试的软件质量很差。但这不是重点。

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

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

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

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