我正在写一篇简短的论文来阐述单元测试和TDD的好处。 我在结尾处包括一小段名为"超越TDD"的小节，我希望其中涵盖基于TDD，BDD和ATDD的几种不同方法。

我对BDD有点熟悉(我曾经在SpecFlow上玩过)，但是在阅读了ATDD之后，听起来非常相似。 BDD和ATDD是否只是本质上相同过程的两个名称-用"普遍存在的语言"记录行为，生成自动验收测试套件，然后使验收测试通过？

stackoverflow.com/questions/4395469/tdd-and-bdd-differences和程序员的可能重复项。stackexchange.com/ questions / 135218 /

TDD和BDD之间的主要区别是什么？

感谢您提供的链接，但这些帖子涵盖了TDD和BDD之间的差异。 我很想知道ATTD和BDD的区别到底是什么-假设ATTD和TTD是不同的(据我所知)。

小的，用ATDD代替ATTD

尽管我总体上同意gishu的职位，但我在几个方面存在分歧。在IMHO部分中，他提出了BDD规范，作为Rachel Davies等人开发的用户故事规范：作为...我想要...这样。

给出了BDD规范...何时...然后...如

Given that the user is logged in, when the user clicks on x, then we should see Y.

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

正如gishu所建议的那样，ATDD是通过使用验收测试规范(作为可执行验收标准来实现)来推动开发的实践。 BDD形式的规范既不是必需的，也不是"最佳实践"。但是，实际上，它可以有效地将思想和语言集中在如何验证工作是否令人满意和满足要求上。

注意，BDD不是特别基于TDD。 ATDD宽松地基于TDD，因为它是在开发完成之前进行的测试。除此之外，它不专注于开发人员的工作，而是专注于项目的总体方向和验证。 ATDD与Story Mapping很好地结合在一起，因为它在编写更高级别的需求时在发现阶段发挥良好的作用，并且重要的是要知道"如何正确完成将如何知道？"

BDD(Dan North，Dave Astels，Dave Chelimsky等人)是一项使整个交付过程变得敏捷的运动。

也就是说，执行BDD的团队将采用ATDD的做法-即从可接受标准的可执行规范开始的过程。一个有效的图形是ATDD包裹了TDD的内部循环。

ATDD只是一种实践，即在开发之前先从可执行的接受标准开始，然后使用它来设计基础代码库的设计(与TDD相似，但层次更大一些)。

以下内容完全是一种观点，可能并不完全准确：

您可能正在执行ATDD，但仍未执行BDD：

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

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

testXDoesY

BDD将其指定为

As a StakeHolder, X should do Y so that I can Z.

最后，我认为主要区别(可能发生但不一定)是ATDD可以变成一个全面的自动化套件，仅作为主动开发和回归的目标。 BDD会恳请您通过可执行示例进一步将问题转移到问题域和解决方案域之间的共享语言+实时文档，从而使将来的建设性对话成为可能

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

我个人喜欢ATDD的概念，因为它与"左移范式"保持一致，在SDLV中应尽早开始开发和测试。从我们从SDLC开始就开始编写自动化测试时，它有助于为自动化带来更多可见性，进而有助于增强团队内部的协作。

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

我不会说太多。我的第一个假设是ATDD，BDD，示例规范，敏捷验收测试等都具有相同的含义。如果有人使用这些术语来表示不同的意思，那么他们会更好地解释这种情况下的区别。