浅谈TDD、BDD、ATDD、DDD的区别

四个开发模式意思:

• TDD：测试驱动开发（Test-Driven Development）
• BDD：行为驱动开发（Behavior Driven Development）
• ATDD：验收测试驱动开发（Acceptance Test Driven Development）
• DDD：领域驱动开发（Domain Drive Design）

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

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

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

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

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

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

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

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

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

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

 

　　进入彩蛋环节：在SBE-Specification by Example(实例化需求说明)的过程和工件有两种流行的模型：以验收>测试为中心的模型和以系统行为规范为主导的模型。

　　以ATDD侧重于自动化测试，并把它作为实例化需求说明过程的一部分。这个模型的主要优点是开发目标更加分明确，并且可以防止功能退化。

　　以BDD侧重于制定系统行为的场景。主要工作是通过协作和需求澄清，在项目干系人和交付团队之间建立共识。

4. DDD：领域驱动开发（Domain Drive Design）

DDD指的是Domain Drive Design，也就是领域驱动开发,DDD实际上也是建立在这个基础之上，因为它关注的是Service层的设计，着重于业务的实现,将分析和设计结合起来，不再使他们处于分裂的状态，这对于我们正确完整的实现客户的需求，以及建立一个具有业务伸缩性的模型