我正在写一篇简短的论文来阐述单元测试和 TDD 的好处。我在最后包含了一个名为“超越 TDD”的小节，我希望在其中特别介绍一些基于 TDD、BDD 和 ATDD 的不同方法。
我对 BDD 有点熟悉（我玩过 SpecFlow），但在阅读了 ATDD 之后，听起来非常相似。 BDD 和 ATDD 是否只是本质上相同过程的两个名称 - 用“普遍存在的”语言记录行为，生成自动化验收测试套件，然后着手让验收测试通过？
【问题讨论】：
我想说这没什么。我的第一个假设是 ATDD、BDD、示例规范、敏捷验收测试等都意味着同样的事情。如果有人使用这些术语来表示不同的事物，那么他们可以更好地解释该上下文中的差异。
【讨论】：
BDD (Dan North, Dave Astels, Dave Chelimsky, et. al) 是一项使整个交付过程变得敏捷的运动。
也就是说，执行 BDD 的团队将采用 ATDD 实践，即从可接受标准的可执行规范开始的过程。 An effective graphic 的重点是 ATDD 包装了 TDD 的内部循环。
ATDD 只是在开发之前从可执行的验收标准开始的实践，并使用它来塑造底层代码库的设计（很像 TDD，但在更粗略的层次上）。
以下内容纯属个人观点，可能并不完全准确： 您可能正在做 ATDD，但仍然没有做 BDD：
例如我可能正在编写自动化验收测试，但它们不可读.. 不传达意图。我可能正在编写一套全面的自动化“回归”测试，但它并没有告诉我系统做什么/它是如何工作的。
测试XDoesY
BDD 会将其指定为
作为利益相关者，X应该做 Y，这样我才能做 Z。
最后，我认为主要的区别（可能会发生但不是必须的）是 ATDD 可以变成一个全面的自动化套件，它只是作为主动开发 + 回归的目标。 BDD 恳请您进一步推动问题和解决方案领域之间的共享语言 + 通过可执行示例实现的实时文档，以实现未来的建设性对话
【讨论】：
虽然我大体上同意 gishu 的帖子，但有几个方面我不同意。在恕我直言的部分，他将 BDD 规范描述为 Rachel Davies 等人开发的用户故事规范：作为...我想要...这样。
BDD 规范是给定的...When... Then... as in
假设用户已登录，当用户点击 x 时，我们应该会看到 Y。
这是关于条件、行动和期望，是 BDD 的核心。
正如 gishu 所建议的那样，ATDD 是通过使用验收测试规范来推动开发的实践，实施为可执行的验收标准。 BDD 形式的规范既不是必需的，也不是“最佳实践”。然而，在实践中，将思维和语言集中在如何验证工作是否令人满意并满足要求上是有效的。
请注意，BDD 并不是特别基于 TDD。 ATDD 松散地基于 TDD，因为它是在开发完成之前完成的测试。除此之外，它不关注开发人员的工作，而是关注项目的整体方向和验证。 ATDD 与 Story Mapping 相得益彰，因为它在编写更高级别需求的发现阶段运行良好，重要的是要知道“我们如何知道它何时已正确完成？”
【讨论】：
ATDD 通常与行为驱动开发 (BDD)、故事测试驱动开发 (SDD) 和示例规范同义使用。与其他敏捷方法相比，ATDD 的主要区别在于，它专注于让开发人员、测试人员、业务、产品所有者和其他利益相关者进行协作，并清楚地了解需要实施的内容。
我个人喜欢 ATDD 的概念，因为它与“Shift Left paradigm”一致，在 SDLC 中应该尽早开始开发和测试。当我们从 SDLC 开始就开始编写自动化测试时，它有助于提高自动化的可见性，进而有助于增强团队内部的协作。
请记住，ATDD 并不是一种万能的解决方案。它是敏捷方法之一。还有许多其他方法可以帮助改进团队中的流程，但我特别发现这种方法专注于更好的验收测试，最重要的是它强调协作；这是这种方法的组成部分。
【讨论】：