测试驱动开发 (TDD) 是近年来越来越流行的一种实践。然而，尽管许多人听说过 TDD，但它的使用仍然不广泛。原因可能有两个：

1. 没人愿意付出努力。

我明白，学习可能会令人恐惧且困难。

1. 我们认为 TDD 不值得。

TDD 显然会使开发时间加倍，对吧？而且对最终产品几乎没有任何好处，对吧？它只是会产生更好的代码，但我们没有时间这样做。

让我们继续讨论第 2 个话题。要使 TDD 有意义，必须满足什么条件？关于 TDD 的哪些证据会让我们更多人接受它？如果答案是它能让开发人员更快、代码更好，那么你就大饱眼福了，因为它（大部分）确实如此。

我不会深入探讨 TDD 研究的结果（尽管我确实总结了行业类别的发现）。本指南的目的是鼓励在研究 TDD 研究时进行深思熟虑的提问和明智的审查。深入研究后，您将能够确定是否要接受 TDD 或避开。有了这种明确性，希望第 1 点不再是问题 - 如果 TDD 值得付出努力，那么付出努力就会变得容易得多。

首先，什么是 TDD？有无数的资源可以解释和演示 TDD。以下是五句话的简单解释：

测试驱动开发是一个由重复的短开发周期形成的过程，通常称为红色、绿色、重构周期。首先，编写一个测试来描述代码应该具有但尚未具有的行为，因此它失败了 - 我们称之为红色测试。然后，您编写最少的代码以快速通过该测试，在此过程中犯下任何必要的错误 - 现在您的测试将通过，我们称之为绿色测试。然后，您可以根据需要重构代码以消除重复或仅仅为了让测试正常运行而创建的不需要的代码 - 这是重构步骤。重构后，重新运行测试以验证没有损坏任何内容。

TDD 流程允许测试指导您的实施，从而产生更易于维护和更高质量的代码。易于维护和高质量的代码并不是我随便编造的好处。研究支持了这一点。

以下是大多数 TDD 研究关注的因素的概述，然后我们可以进行更深入的挖掘。

别让我在这里迷失你。如果你不注重细节，请跳过接下来的几个小节并查看行业结论。

大多数研究关注四个因素：内部质量、外部质量、测试质量和生产率。具体来说，TDD 是改善了这些因素，还是阻碍了这些因素？

• 内部质量与系统设计有关。TDD 是否使代码更易于使用和理解？代码是否更易于维护？
• 外部质量与缺陷有关。TDD 是否减少了应用程序中的错误数量？
• 测试质量就是测试质量。如果工程师使用 TDD 而不是其他测试策略，这些测试的有效性是否会有实质性差异？
• 生产力与开发人员的效率有关。TDD 是否能让软件开发人员更快地交付软件？

根据研究的规模和主题，研究也有不同的类别：对照实验、试点研究、半工业研究和工业研究。

• 受控实验是具有明确研究协议的学术实验室或受控行业环境。
• 试点研究是结构性较弱的实验任务。
• 半工业化是指专业开发人员从事实验项目或学生开发人员从事真实项目。
• 行业研究与现实世界最为相似——它们专注于将 TDD 作为日常工作一部分的行业团队。

我不会对所有测量和类别的结果进行逐一介绍。以下是我的课程《什么是 TDD 以及为什么它不是单元测试：执行简报》中的一个有用的表格。

请注意行业类别的结果：

1. 采用 TDD 后内部质量更好。

2. 采用 TDD 后，外部质量更好。

3. 测试质量尚无定论。一项研究指出，TDD 可提高测试覆盖率，而不会影响生产率。但最终，没有足够的证据从测试密度和测试生产率等指标得出结论。VTT案例研究

4. 生产力在短期内会受到打击，但从长远来看可能会有所改善（从长远来看，第 1 点和第 2 点将带来生产力的提升）。需要进行更多研究才能全面评估对长期生产力的影响。

由于本指南并非详尽的研究（有数十项研究可供参考），因此重要的是学习如何评估 TDD 研究。在广泛研究了 TDD 研究后，很明显，TDD 研究的开展和衡量方式存在很大差异。因此，虽然我们可以在研究中看到共同点并得出一些相当一致的结论（如上一节所述），但这些差异可能对您来说很重要。我将在这里为您提供一些工具，以便您可以自行深入研究并确定这些差异是否与您的情况相关且对您很重要。

免责声明：我不是一名专业或受过教育的研究人员，也没有权力对任何研究进行资格审查或取消资格审查。这些​​都是在研究 TDD 研究时值得考虑的重要因素。

需要考虑的主要因素包括指标、TDD 流程、控制组、依从性、主题团队和代码库大小以及技术堆栈。

• 使用了哪些指标？如何测量？例如，一项研究在评估测试质量时只关注测试覆盖率。质量测试远不止测试覆盖率，因此这些研究对您来说可能并不重要。另一个例子：如何计算错误频率？它是基于报告的错误吗？如果报告错误的流程非常繁琐怎么办？那些发现错误却不报告的人（我们大多数人）怎么办？这可能会扭曲结果。
• TDD 是如何实践的？它是真正的 TDD 还是测试优先？一些研究没有准确解释所使用的 TDD 流程，这意味着它可能更像是一种测试优先方法（首先进行一对多测试，然后进行生产代码），而不是 TDD（进行一次测试，然后编写尽可能简单的代码）。
• 使用的对照是什么？通常是一个非 TDD 团队，这让我们无法了解 TDD 与事后测试相比的优势。或者有时对照组应该在事后编写自动化测试，但却未能始终如一地这样做，这导致对开发人员生产力的影响的描述不准确。（微软研究中引用了 John Deere 的研究）。密切关注所使用的对照，因为设计不当的研究可能会完全扭曲结果。
• 是否关注了依从性？是否始终如一地践行？受试者是否有过 TDD 经验？是否有经验丰富的人教过他们，还是他们自己学习的？
• 研究的团队和项目有多大？如果你在行业内工作，那么一项只有 5800 行代码的内部产品研究（我见过声称是行业级研究 https://arxiv.org/pdf/1711.05082.pdf）可能对你来说意义不大。
• 他们使用了哪些语言和框架？他们选择的语言是否允许访问成熟的测试库/框架？还是这迫使他们进入一个 TDD 很少见且充满障碍的世界？此外，您是否只关心使用您选择的语言的研究？

其他考虑因素：

• 有没有提到受试者学习和熟练掌握 TDD 有多困难？如果研究持续两个月，但需要两个月才能熟练掌握 TDD，结果可能不准确。

有一些关于 TDD 的说法很难衡量，因此很可能仍是无效的说法。它们是什么？

• TDD 创建了可用作文档的测试。该文档缩短了开发人员的入职时间或代码库的交接时间。它还提高了对失去知识人才的适应能力。
• TDD 提高了开发人员的保留率，因为它使他们的工作更轻松、更令人满意。
• TDD 增加了开发人员的责任感和对质量的关注。
• TDD 帮助开发人员专注于解决正确的问题，从而提高他们的效率，并帮助交付更好地满足客户需求的软件。

这些因素对你来说重要吗？在决定你是否使用 TDD 时，它们占多大比重？如果它们是主要因素，你必须决定是否要依赖 TDD 支持者的主张并对其进行测试（双关语），或者在采用 TDD 之前是否需要强有力的证据。

如上所述，目前已有数十项研究和相关书籍。您会发现这些资源是一个很好的起点，如果您想进一步挖掘，您可以查看它们引用的来源并找到您自己的来源。

[微软与 IBM 联合研究]（https://www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan_tdd.pdf）

他们比较了同一位经理领导下的多个团队。他们研究了使用 TDD 的团队和未使用 TDD 的团队的结果。最大的收获是缺陷减少了 60-90%，项目完成时间增加了 15-35%（但团队一致认为这被维护成本的降低所抵消）。

[测试驱动开发：以 Kent Beck 为例]（https://www.oreilly.com/library/view/test-driven-development/0321146530/）

这更多地侧重于如何实践 TDD，但也包括支持 TDD 的精彩解释和证据。

[制作软件]（https://www.oreilly.com/library/view/making-software/9780596808310/）> 第 12 章的标题为“测试驱动开发有多有效？”，其中引入了 22 个临床试验参考文献和 4 个一般参考文献。

客座编辑介绍：TDD——无畏编程的艺术

概述了 TDD 的一些难以衡量的好处，以及 TDD 研究现状的概要（2007 年出版）。

有许多研究对 TDD 进行了测试。其中大多数研究都关注质量和生产力，但 TDD 研究的设计方式存在很大差异。有些资源提供了 TDD 研究的高级概述，这些信息可能对您来说足够了。如果您想深入研究，重要的是仔细研究影响研究结果的不同因素。最后，研究证据通常对 TDD 有利。它可以提高代码质量，减少错误数量，并可能带来长期生产力。我鼓励您自己仔细研究一下，并做出有意识的决定，接受或拒绝 TDD。