测试驱动开发(TDD)和行为驱动开发(BDD?)都是软件开发的测试优先方法。它们共享共同的概念和范式，植根于相同的哲学。在本文中，我们将重点介绍这两种方法的共性、差异、优缺点。

什么是测试驱动开发（TDD）

测试驱动开发(TDD)是一种依赖于重复短开发周期的软件开发过程：需求转化为非常具体的测试用例。编写代码是为了使测试通过。对代码进行重构和改进，以确保代码质量并消除任何技术债务。这个循环被称为Red-Green-Refactor循环。

行为驱动开发(BDD)是一个软件开发过程，它鼓励参与项目交付的所有各方之间的协作。它鼓励以各方都能理解的通用语言对系统行为进行定义和形式化，并将此定义用作基于TDD的流程的种子。

交付预期的系统行为

自下而上或自上而下（验收测试驱动开发）

包括客户在内的所有团队成员

符合我们测试标准的功能系统

一个按预期运行的系统和一个用人类通用语言描述系统行为的测试套件

过度工程、低测试覆盖率和低价值测试

偏离预期的系统行为

实现的变化可能导致测试套件的变化

如果需要更改系统行为，则仅需要更改测试套件

自底向上比较简单，自顶向下比较难

为所有相关方提供更大的学习曲线

在TDD中，我们有众所周知的Red-Green-Refactor循环。我们从一个失败的测试开始（红色），并尽可能少地实现代码以使其通过（绿色）。此过程也称为测试优先开发。TDD还增加了一个Refactor阶段，这对整体成功同样重要。

TDD方法是由单元测试和后来的TDD、敏捷软件开发和最终极限编程的先驱之一的KentBeck发现（或可能重新发现）的。

下图很好地提供了一个易于理解的过程概述。美在于细节。在深入研究每个单独的阶段之前，我们还必须讨论TDD的两种高级方法，即自下而上和自上而下的TDD。

自底向上TDD（也称为Inside-OutTDD）背后的理念是迭代地构建功能，一次只关注一个实体，在移动到其他实体和其他层之前巩固其行为。

我们首先编写单元级测试，继续执行它们，然后继续编写高级测试，聚合低级测试的功能，创建所述聚合测试的实现，等等。通过逐层构建，我们最终将达到一个阶段，即聚合测试是一个验收水平测试，希望符合所要求的功能。此过程使其成为一种高度以开发人员为中心的方法，主要旨在使开发人员的生活更轻松。

一次只关注一个功能实体

功能实体易于识别

实体需要暴露的行为数量尚不清楚

不需要高水平的愿景开始

实体之间无法正确交互从而需要重构的高风险

业务逻辑可能分布在多个实体中，使其不清楚且难以测试

自上而下的TDD也称为外向内TDD或验收测试驱动开发(ATDD)。它采取相反的方法。我们开始构建一个系统，迭代地为实现添加更多细节。随着重构机会变得明显，迭代地将其分解为更小的实体。

我们首先编写一个可接受级别的测试，然后进行最少的实现。该测试也需要逐步进行。因此，在创建任何新实体或方法之前，需要在适当级别进行测试。因此，我们迭代地改进解决方案，直到它解决了启动整个练习的问题，即验收测试。

这种设置使自上而下的TDD成为一种更加以业务/客户为中心的方法。这种方法更难正确，因为它在很大程度上依赖于客户和团队之间的良好沟通。它还需要开发人员的良好公民身份，因为需要仔细考虑下一个迭代步骤。这个过程会及时加快，但确实有一个学习曲线。好处远远超过任何负面影响。这种方法导致客户和团队之间的协作成为中心舞台，一个具有非常明确的行为、明确定义的流程、专注于首先集成以及非常可预测的工作流程和结果的系统。

一次只关注一个用户请求的场景

获得正确的断言测试至关重要，因此需要业务/用户/客户和团队之间的协作讨论

依赖于Stubbing、Mocking和/或测试替身

重点是集成而不是实现细节

由于通过多次迭代识别流程，因此启动较慢

一个实体需要暴露的行为数量是明确的

用户需求、系统设计和实施细节都清楚地反映在测试套件中

有了上面讨论过的关于如何处理TDD的高级愿景，我们可以自由地深入研究Red-Green-Refactor流程的三个核心阶段。

我们首先编写一个测试，执行它（因此失败），然后才开始执行该测试。在这里编写正确的测试至关重要，就我们试图实现的测试层达成一致也是如此。这将是验收水平测试还是单元水平测试？这种选择是自下而上和自上而下TDD之间的主要界限。

在绿色阶段，我们必须创建一个实现以使红色阶段中定义的测试通过。实现应该是尽可能最小的实现，使测试通过，仅此而已。运行测试并观察它通过。

创建尽可能最小的实现通常是这里的挑战，因为开发人员可能倾向于通过习惯的力量立即美化实现。这个结果是不可取的，因为它会产生技术包袱，随着时间的推移，这将使重构更加昂贵，并可能基于重构成本扭曲系统。通过使每个实施步骤尽可能小，我们进一步强调了我们试图实施的过程的迭代性质。此功能将赋予我们敏捷性。

另一个关键方面是红色阶段，即测试，是推动绿色阶段的动力。任何实现都不应该由非常具体的测试驱动。如果我们采用自下而上的方法，这很自然。如果我们采用自上而下的方法，那么我们必须更加认真，并确保在实现形成时创建进一步的测试，从而从验收级别测试转向单元级别测试。

重构阶段是TDD的第三个支柱。这里的目标是重新审视和改进实施。优化了实现，提高了代码质量，消除了冗余。

重构对许多人来说可能具有负面含义，被视为纯粹的成本，在第一次就修复了不正确的事情。这种看法源于更传统的工作流程，其中重构主要只在必要时进行，通常是在技术包袱达到无法维持的水平时，从而导致冗长、昂贵的重构工作。

在这里，重构是工作流的固有部分，并且是迭代执行的。这种灵活性极大地降低了重构的成本。代码没有完全重做。相反，它正在缓慢发展。此外，根据定义，重构的代码包含在测试中。在之前的代码迭代中已经通过的测试。因此，可以放心地进行重构，从而进一步加快速度。此外，这种改进代码库的迭代方法允许紧急设计，这大大降低了过度设计问题的风险。

行为不应该改变是至关重要的，我们不会在重构阶段添加额外的功能。这个过程允许以极大的信心和敏捷性进行重构，因为根据定义，相关代码已经被测试覆盖。

如前所述，TDD（或自下而上的TDD）是一种以开发人员为中心的方法，旨在生成更好的代码库和更好的测试套件。相比之下，ATDD更加以客户为中心，旨在提供更好的整体解决方案。我们可以将行为驱动开发视为ATDD的下一个逻辑进展。DanNorth在TDD和ATDD方面的经验导致他提出了BDD概念，其想法和主张是将TDD和ATDD的最佳方面结合在一起，同时消除他在这两种方法中发现的痛点。他发现，具有描述性的测试名称很有帮助，而且测试行为比功能测试更有价值。

DanNorth将BDD简洁地描述为“使用多个级别的示例来创建共享理解和表面确定性以交付重要的软件”，做得很好。

BDD将责任更多地放在客户和团队之间富有成效的协作上。正确定义系统的行为变得更加关键，从而导致正确的行为测试。这里的一个常见陷阱是对系统将如何实施行为做出假设。这个错误发生在被实现细节污染的测试中，因此使其成为功能测试而不是真正的行为测试。这个错误是我们想要避免的。

行为测试的价值在于它测试了系统。它不关心它是如何实现结果的。这种设置意味着行为测试不应随时间而改变。除非行为本身需要作为功能请求的一部分进行更改。功能测试的成本效益更为显着，因为此类测试通常与实现紧密耦合，以至于代码的重构也涉及测试的重构。

更大的好处是保留了表面确定性。在功能测试中，代码重构也可能需要测试重构，这不可避免地会导致失去信心。如果测试失败，我们不确定原因可能是什么：代码、测试或两者兼而有之。即使测试通过，我们也不能确信之前的行为已经被保留。我们所知道的是测试与实现相匹配。这个结果的价值很低，因为最终客户关心的是系统的行为。因此，我们需要测试和保证的是系统的行为。

基于BDD的方法应该导致完整的测试覆盖，其中行为测试使用通用语言向所有各方充分描述系统的行为。与功能测试相比，即使完全覆盖也不能保证系统是否满足客户的需求，重构测试套件本身的风险和成本只会随着覆盖率的增加而增加。当然，通过自上而下地从行为测试到更多功能测试来利用这两种方法，将为行为测试带来表面确定性的好处。此外，功能测试以开发人员为中心的好处也抑制了功能测试的成本和风险，因为它们只在适当的地方使用。

在直接比较TDD和BDD时，主要变化是：

出现了框架和工具的生态系统，以允许跨团队进行基于通用语言的协作。以及通过利用行业标准工具来集成和执行测试等行为。这方面的例子包括Cucumber、JBehave和Fitnesse等等。

正如我们所看到的，TDD和BDD之间并没有真正的直接竞争。将BDD视为TDD和ATDD的进一步发展，它带来了更多以客户为中心，并进一步强调了客户与技术团队在流程的所有阶段之间的沟通。这样做的结果是一个系统，其行为符合所有相关方的预期，以及一个测试套件，以人类可读的方式描述系统的许多行为，每个人都可以访问并易于理解。反过来，该系统不仅对已实施的系统，而且对系统的未来更改、重构和维护提供了非常高的信心。

同时，BDD很大程度上基于TDD流程，并进行了一些关键更改。虽然客户或团队的特定成员可能主要参与系统的最顶层，但其他团队成员（如开发人员和QA工程师）会在他们以自己的方式在顶层工作时从BDD有机地转变为TDD模型。下来时尚。

在某些情况下，BDD可能不是合适的选择。在某些情况下，所讨论的系统技术性很强，可能根本不面向客户。它使需求与功能的联系比与行为的联系更紧密，从而使TDD可能更适合。

最终，问题不应该是采用TDD还是BDD，而是哪种方法最适合手头的任务。很多时候，这个问题的答案是两者兼而有之。随着越来越多的人参与到更重要的项目中，不言而喻的是，在整个项目生命周期的不同级别和不同时间都需要这两种方法。TDD将为技术团队提供结构和信心。BDD将促进和强调所有相关方之间的沟通，并最终交付满足客户期望的产品，并提供所需的表面确定性，以确保对未来进一步发展产品的信心。

通常情况下，这里没有灵丹妙药。相反，我们拥有的是一些非常有效的方法。两者的知识将使团队能够根据项目的需要确定最佳方法。进一步的经验和执行的流畅性将使团队能够在整个项目生命周期中根据需要使用其工具箱中的所有工具，从而实现最佳的业务成果。