BDD之单元测试（二）：ATDD，TDD，BDD的区别

朱雀 2020-10-25 07:32 692阅读 0赞

# ATDD： Acceptance Test Driven Development（验收测试驱动开发）

这是一种在编码开始之前将客户带入测试设计过程的技术。它也是一个协作实践，用户，测试人员和开发人员定义了自动验收标准。 ATDD有助于确保所有项目成员准确理解需要完成和实施的内容。如果系统未通过测试可提供快速反馈，说明未满足要求。验收测试以业务领域术语进行指定。每个功能都必须提供真实且可衡量的业务价值，事实上，如果您的功能没有追溯至至少一个业务目标，那么您应该想知道为什么您要首先实施它。

# TDD： Test-driven development （测试驱动开发）

是一种使用自动化单元测试来推动软件设计并强制依赖关系解耦的技术。使用这种做法的结果是一套全面的单元测试，可随时运行，以提供软件可以正常工作的反馈。

踢踏舞.png

*TDD重点是培养整个研发过程的节奏感，就像跳踢踏舞一样，“ti-ta-ti”。*

在编写真正实现功能的代码之前先编写测试，每次测试之后，重构完成，然后再次执行相同或类似的测试。该过程根据需要重复多次，直到每个单元根据所需的规格运行。

# BDD:Behavior-Driven Development (行为驱动开发)

BDD将TDD的一般技术和原理与领域驱动设计(DDD)的想法相结合。 BDD是一个设计活动，您可以根据预期行为逐步构建功能块。

*BDD的重点是软件开发过程中使用的语言和交互。*

行为驱动的开发人员使用他们的母语与领域驱动设计的语言相结合来描述他们的代码的目的和好处。

使用BDD的团队应该能够以用户故事的形式提供大量的“功能文档”，并增加可执行场景或示例。 BDD通常有助于领域专家理解实现而不是暴露代码级别测试。它通常以GWT格式定义：GIVEN WHEN＆THEN。

| 区别项             | ATDD                                                         | TDD                                                          | BDD                                                          |
| ------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 参与者和范围       | 业务用户，开发人员，测试人员之间的沟通机制以确保需求得到充分记录 | 开发人员和测试人员之间的开发方法，以创建良好的代码单元（模块，类，功能） | ATDD和TDD的组合。                                            |
| 重点               | 专注于提取用户验收测试中的要求并用于推动开发。是一种使客户进入设计阶段的技术 | 一种模式和范例                                               | 专注于客户和开发者的系统行为方面，仍然是偏向于不断测试的实践来引导客户进入测试阶段，并通过逐步关注其行为进行认证。 |
| 敏捷步骤           | 1. 讨论   2. 开发   3.发布   不断重复                        | 1. 测试   2.编码  3.重构   不断重复                          | 按预期行为逐步构建功能。  它是TDD和编写使功能/行为失败的测试的延伸 |
| 输入文档           | 验收标准+示例（数据和方案）=验收测试需求文档将作为开发和测试的基础。 | 需求文档                                                     | 用GWT格式书写的实例化文档，有时也需要验收标准                |
| 自动化要求         | 不是必须，但是可在回顾测试时实现                             | 必须                                                         | 必须                                                         |
| 故事/特性/测试地图 | 每个故事都应对应一个验收测试                                 | 每个功能都需要对应一个测试                                   | 每个故事应对应一个行为测试                                   |
| 主流工具           | · Robot Framework  · FitNesse  ·FIT                          | Xunit framework                                              | Cucumber JBehave, Concordian，[lettuce](https://www.jianshu.com/p/057dbae54134),Robot Framework |
| 最终用户           | 客户                                                         | 开发人员，测试人员                                           | 客户和开发者                                                 |

> 在SBE-Specification by Example(实例化需求说明)的过程和工件有两种流行的模型：以验收>测试为中心的模型和以系统行为规范为主导的模型。
>
> 以ATDD侧重于自动化测试，并把它作为实例化需求说明过程的一部分。这个模型的主要优点是开发目标更加分明确，并且可以防止功能退化。
>
> 以BDD侧重于制定系统行为的场景。主要工作是通过协作和需求澄清，在项目干系人和交付团队之间建立共识。

[BDD之单元测试（一）：BDD出现的背景 ](/article/details/1025033215120569)

[BDD之单元测试（三）：BDD的官方教程](/article/details/1025033304630690)

[BDD之单元测试（四）：实际的项目教程](/article/details/1025033315732569)