单元测试对我来说听起来很棒，但我不确定我是否应该花时间真正学习它，除非我能说服其他人认为它具有重要价值。我必须说服其他程序员，更重要的是，说服管理中的 bean-counters，所有花在学习测试框架、编写测试、更新测试等的额外时间都会为自己付出代价，然后是一些。
有什么证据？有没有人真的用两个独立的团队开发过相同的软件，一个使用单元测试，另一个不使用，并比较结果？我对此表示怀疑。我是否应该用“在互联网上查找它，每个人都在谈论它，所以它一定是正确的做法”来证明它的合理性？
让外行相信单元测试值得付出努力的确凿证据在哪里？
“我必须说服其他程序员，更重要的是，说服管理中的 bean-counters，所有花费在学习测试框架、编写测试、更新测试等的额外时间都会为自己付出代价，然后再花一些时间。 "
为什么？
为什么不只是安静而谨慎地去做。您不必一次完成所有操作。你可以用小块做这个。
框架学习只需要很少的时间。
只写一个测试，只需要很少的时间。
如果没有单元测试，你所拥有的只是对你的软件有一些信心。通过一次单元测试，您仍然有信心，并证明至少通过了一项测试。
这就是它所需要的。没有人需要知道你在做什么。去做就对了。
我对此采取了不同的方法：
你有什么保证你的代码是正确的？或者当您的团队中有人更改 func1() 时，它不会破坏假设 X？如果没有单元测试让你保持“诚实”，我不确定你是否有足够的把握。
保持测试更新的概念很有趣。测试本身不需要经常改变。与生产代码相比，我得到了 3 倍的测试代码，而且测试代码几乎没有改变。然而，正是它让我晚上睡得很好，让我告诉客户我有信心在不破坏系统的情况下实现 Y 功能。
也许在学术界有证据，但我从来没有在商业世界的任何地方工作过，任何人都会为这样的测试付费。然而，我可以告诉你，它对我来说效果很好，很快就习惯了测试框架，编写测试让我真正思考了我的需求和设计，这比我在团队中工作时所做的要多得多没有写测试。
这是它为自己付出代价的地方：1）您对自己的代码有信心，2）您比其他方式更早地发现问题。您不会让 QA 人员说“嘿，您没有费心检查 xyz() 函数的边界，是吗？ 他没有找到那个错误，因为您在一个月前发现了它。这对他，对你好，对公司好，对客户好。
显然这是轶事，但它对我产生了奇迹。不确定我是否可以为您提供电子表格，但我的客户很高兴，这就是最终目标。
我们已经用确凿的证据证明，没有单元测试也可以编写蹩脚的软件。我相信甚至有证据表明单元测试是糟糕的软件。但这不是重点。
单元测试或测试驱动开发 (TDD) 是一种设计技术，而不是测试技术。编写测试驱动的代码看起来与非测试驱动的代码完全不同。
尽管这不是您的问题，但我想知道这是否真的是最简单的方法来回答可能被问错的问题（并带来可能会受到其他报告质疑的证据）。即使您为您的案件找到了确凿的证据——其他人也可能找到反对的确凿证据。
决定技术人员应该如何工作是豆类计数器的业务吗？他们是否在所有情况下都提供最便宜的工具，因为他们认为您不需要更昂贵的工具？
这个论点要么基于信任（敏捷团队的基本价值观之一）获胜，要么基于获胜方的角色权力而失败。即使 TDD 支持者基于角色权力获胜，我也会将其视为失败。
更多关于 TDD 而不是严格的单元测试，这里是通过测试驱动开发实现质量改进的链接：四个工业团队的结果和经验论文，由 Nagappan、E. Michael Maximilien、Thirumalesh Bhat 和 Laurie Williams 撰写。微软经验软件工程与测量(ESM) 小组发表的论文，已在此处提及。
该团队发现，TDD 团队生成的代码（就缺陷密度而言）比非 TDD 团队好 60% 到 90%。然而，TDD 团队完成项目的时间要长 15% 到 35%。
如果您也对反对单元测试的证据感兴趣，这里有一篇经过充分研究和深思熟虑的文章：
这是一本关于一个从内部改变公司的人的精彩而有趣的读物。它不仅限于 TDD。http://jamesshore.com/Change-Diary/请注意，他很长一段时间都没有说服“bean counters”，而是采取了“游击战术”。
只是为了向这些答案添加更多信息，有两个元分析资源可能有助于弄清楚生产力和质量对学术和行业背景的影响：
所有研究人员似乎都同意 TDD 鼓励更好的任务重点和测试覆盖率。更多测试这一事实并不一定意味着软件质量会更好，但程序员对测试设计的关注度增加仍然令人鼓舞。如果我们将测试视为对大量潜在行为进行抽样，那么更多的测试意味着更彻底的样本。如果每个测试都可以找到其他测试都找不到的重要问题，那么这些测试很有用，特别是如果您可以廉价地运行它们。
表 1. 测试驱动开发的部分实证研究总结：行业参与者*
表 2. TDD 实证研究的摘要：学术参与者*
抽象的：
本文对 27 项研究进行了系统的元分析，这些研究调查了测试驱动开发 (TDD) 对外部代码质量和生产力的影响。
结果表明，总体而言，TDD 对质量的积极影响很小，但对生产力的影响很小甚至没有明显影响。然而，亚组分析发现，与学术研究相比，工业研究的质量提高和生产率下降要大得多。在 TDD 和对照组的过程之间的测试工作量差异显着的研究中发现了更大的生产力下降。当测试努力的差异很大时，学术研究中的质量也有较大的提高；然而，由于缺乏数据，无法就工业研究得出结论。
最后，研究了开发人员经验和任务规模作为调节变量的影响，发现任务规模与质量改进幅度之间存在统计学上显着的正相关关系。
有统计数据证明，修复单元/集成测试中发现的错误比在实时系统上修复的成本要低很多倍（它们基于监控数千个现实生活项目）。
编辑：例如，正如所指出的，“代码完成”一书报告了此类研究（第 20.3 段，“质量技术的相对有效性”）。但咨询领域的私人研究也证明了这一点。
嗯，有一些大公司要求你使用单元测试，但如果你是一家小公司，为什么要模仿大公司呢？
对我来说，当我多年前开始进行单元测试时（今天我们主要使用行为模型），那是因为我无法在一个应用程序中控制所有路径。
我习惯于首先编程和 REPL，所以当我得到单元测试（每个函数一个测试）时，就像将 REPL 带回了非常容易编译的语言。它给我写的每一行代码带来了乐趣。我觉得上帝。我喜欢它。我不需要报告来告诉我我开始更快地编写更好的代码。我的老板不需要报告就可以注意到，因为我们在做疯狂的事情时突然从未错过最后期限。我的老板不需要报告来注意到“普通”错误的数量从（很多）下降到几乎为零，因为编写非生产性代码这种非常奇怪的事情。
正如另一位海报已经写的那样，您不使用 TDD 来测试（验证）。您编写它来捕获规范，即您的单元（对象、模块、函数、类、服务器、集群）工作的行为。
在许多公司中，有很多失败和成功的案例切换到不同的软件开发模型。
每当我有新东西要写时，我就开始使用它。有句老话对我来说翻译成英文有点困难，但是：
从简单到你没有注意到你做了的事情开始。马拉松训练时，从步行 9 米开始，然后跑 1 米，重复。
我确实有一组数据点 - 从单元测试卖给我的经验。
很多个月前，我是一名刚毕业的学生，正在从事一个大型 VB6 项目，并且有机会编写大量存储过程代码。在我编写的子系统中，它约占整个代码库的 1/4——大约 50K 左右的 13,000 LOC。
我为存储过程编写了一组单元测试，但是如果没有像 Rational Robot 这样的工具，对 VB6 UI 代码进行单元测试是不可行的；至少那时不是。
QA 对这件作品的统计是，整个子系统产生了大约 40 或 50 个缺陷，其中两个来自存储过程。这是每 6,500 行代码中有一个缺陷，而整段代码中每 1,000-1,200 行有 1 个缺陷。还要记住，大约 2/3 的 VB6 代码是用于错误处理和日志记录的样板代码，在所有过程中都是相同的。
无需过多的手动操作，您就可以将缺陷率至少提高一个数量级归因于单元测试。
