行为驱动开发(BDD)和验收测试驱动开发(ATDD)之间的区别是什么？

Question

我正在写一篇短文来阐述单元测试和TDD的好处。我在结尾处加入了一个标题为“超越TDD”的简短部分，其中我希望特别介绍几种基于TDD、BDD和ATDD的不同方法。

我对BDD比较熟悉(我曾经用过SpecFlow)，但在阅读了ATDD之后，它听起来非常相似。BDD和ATDD只是本质上相同的过程的两个名字--用一种“无处不在的”语言记录行为，生成一个自动验收测试套件，然后让验收测试通过？

Answer 1

虽然我总体上同意gishu的帖子，但有几个领域我不同意。在IMHO部分，他介绍了BDD规范作为由瑞秋·戴维斯等人开发的用户故事规范:作为一个...我想..。所以。

给出了BDD规范...当..。然后..。如图所示

假设用户已经登录，当用户点击

时，我们应该看到Y。

这是关于条件、操作和期望的，并且是BDD的核心。

正如gishu建议的那样，ATDD是通过使用验收测试规范来推动开发的实践，作为可执行的验收标准来实现。BDD形式的规范既不是必需的，也不是“最佳实践”。然而，在实践中，它有效地将思维和语言集中在如何验证工作已经完成并满足要求上。

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

Answer 2

BDD (Dan North，Dave Astels，Dave Chelimsky，et.al)是一种让整个交付过程变得敏捷的运动。

也就是说，进行BDD的团队将采用ATDD的实践-即从验收标准的可执行规范开始的过程。要指出的是，An effective graphic包装了测试驱动开发的内部循环。

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

以下内容完全是一种观点，可能并不完全准确:您可能正在执行ATDD，但仍未执行BDD：

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

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

测试XDoesY

BDD会将其指定为

作为一个StakeHolder，X do Y这样我就可以Z.

最后，我认为主要的不同之处(可能会发生，但不是必须的)是ATDD可以变成一个全面的自动化套件，它只是作为主动开发+回归的目标。BDD将恳求您进一步关注问题和解决方案领域之间的共享语言+ living documentation通过可执行示例实现未来的建设性对话

Answer 3

ATDD通常与行为驱动开发(BDD)、故事测试驱动开发(SDD)和通过示例进行规范是同义词。与其他敏捷方法相比，ATDD的主要区别是，它的重点是让开发人员、测试人员、业务、产品所有者和其他利益相关者协作，并对需要实现的内容进行清晰的理解。

我个人喜欢ATDD的概念，因为它与“Shift Left paradigm”保持一致，即开发和测试应该在SDLC中尽早开始。它有助于将更多的可见性带入自动化，因为我们从SDLC的开始就开始编写自动化测试，并反过来帮助增加团队内的协作。

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