tdd - 行为驱动开发 (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 的实践——即从可接受标准的可执行规范开始的过程。一个有效的说明图是 ATDD 包装 TDD 的内部循环的地方。

ATDD 只是在开发之前从可执行的验收标准开始并使用它来塑造底层代码库的设计（很像 TDD，但在更粗略的级别）的实践。

以下内容完全是一种观点，可能并不完全准确： 您可能正在做 ATDD，但仍然没有做 BDD：

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

• BDD 非常强调语言和交流。例如指定行为，而不是说

测试XDoesY

BDD 会将其指定为

作为利益相关者，X应该做 Y，这样我才能做 Z。

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

Answer 3

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

我个人喜欢 ATDD 的概念，因为它符合“<a href="https://insights.sei.cmu.edu/sei_blog/2015/03/four-types-of-shift-left-testing.html” rel="nofollow noreferrer">Shift Left 范式”，在 SDLC 中应尽早开始开发和测试。当我们从 SDLC 开始就开始编写自动化测试时，它有助于提高自动化的可见性，进而有助于增强团队内部的协作。

请记住，ATDD 并不是一种万能的解决方案。它是敏捷方法之一。还有许多其他方法可以帮助改进团队中的流程，但我特别发现这种方法专注于更好的验收测试，最重要的是它强调协作；这是这种方法的组成部分。

Answer 4

我会说没什么。我的第一个假设是 ATDD、BDD、示例规范、敏捷验收测试等都意味着同样的事情。如果有人使用这些术语来表示不同的事物，那么他们可以更好地解释该上下文中的差异。