行为驱动开发（BDD）和验收测试驱动开发（ATDD）之间有什么区别？

Question

我正在写一篇简短的论文来阐述单元测试和TDD的好处。我在最后加入了一个名为“超越TDD”的简短部分，其中我希望能够涵盖基于TDD，BDD和ATDD的几种不同方法。

我对BDD很熟悉（我玩过SpecFlow），但在读完ATDD之后，听起来非常相似。 BDD和ATDD只是基本上相同过程的两个名称 - 以“无处不在的”语言记录行为，生成自动验收测试套件，然后继续进行验收测试？

Answer 1

虽然我同意一般与gishu的帖子，但有几个方面我不同意。在恕我直言部分，他将BDD规范作为由Rachel Davies等人开发的用户故事规范提出：作为......我想要......所以。

BDD规范是给定的...当......然后......如

  

鉴于用户已登录，当用户点击x时，我们应该看到Y。

这是关于条件，行动和期望，是BDD的核心。

正如gishu所建议的那样，ATDD是通过使用验收测试规范来推动开发的实践，该规范被实施为可执行的验收标准。 BDD形式的规范既不是必需的，也不是“最佳实践”。然而，在实践中，将思维和语言集中在如何验证工作是否令人满意并满足要求方面是有效的。

请注意，BDD并非特别基于TDD。 ATDD松散地基于TDD，因为它是在开发完成之前完成的测试。除此之外，它不是关注开发人员的工作，而是关注项目的整体方向和验证。 ATDD与Story Mapping很好地融合在一起，因为它在发现阶段发挥得很好，当时正在编写更高级别的要求，并且知道“我们将如何知道它何时正确完成？”很重要。

Answer 2

BDD（Dan North，Dave Astels，Dave Chelimsky等人）是一个让整个交付过程变得敏捷的运动。

那说做BDD的团队将采用ATDD的做法 - 即以可接受标准的可执行规范开始的过程。 An effective graphic提出要点是ATDD包含TDD内循环的地方。

ATDD只是在开发之前从可执行验收标准开始并使用它来塑造底层代码库的设计（非常类似于TDD，但处于更笨重的级别）的做法。

以下内容完全是恕我直言，可能并不完全准确： 你可能正在做ATDD，但仍然没有做BDD：

e.g。我可能正在编写自动验收测试，但这些测试是不可读的......它们没有传达意图。我可以编写一套全面的自动“回归”测试，但不告诉我系统做了什么/它是如何工作的。

• BDD强调语言和沟通。例如指定行为，而不是说

  

* 测试 * XDoesY

BDD会将其指定为

  

作为StakeHolder，X 应做Y，以便我可以Z.

所以关闭，我认为主要的区别（可能会发生但不必）是ATDD可以变成一个全面的自动化套件，只是作为积极开发+回归的目标。 BDD会恳请您将针头进一步转移到问题域和解决方案域之间的共享语言 +通过可执行示例的活文档，以便进行未来的建设性对话

Answer 3

我会说没什么。我的第一个假设是ATDD，BDD，示例规范，敏捷验收测试等都意味着相同的事情。如果有人使用这些术语以便它们意味着分开的东西，那么他们就能更好地解释这种背景下的差异。

Answer 4

ATDD通常与行为驱动开发（BDD），故事测试驱动开发（SDD）和按示例规范同义使用。与其他敏捷方法相比，ATDD的主要区别在于，它致力于使开发人员，测试人员，业务人员，产品所有者和其他利益相关者进行协作，并清楚地了解需要实施的内容。

我个人喜欢ATDD的概念，因为它与“Shift Left paradigm”对齐，其中开发和测试应尽早在SDLC中开始。当我们从SDLC开始就开始编写自动化测试时，它有助于提高自动化的可视性，从而有助于增强团队内的协作。

请记住，ATDD不是全部，适合所有类型的解决方案。这是一种敏捷方法。还有其他各种方法可以帮助改进团队流程，但我特别发现这种方法专注于更好的验收测试，最重要的是它强调协作;这是这种方法的组成部分。

-Raj

Testim.io