What are the primary differences between TDD and BDD?在过去的几年中，测试驱动开发一直是.NET社区中的热门话题。 最近，我在ALT.NET社区中听到有关BDD的抱怨。 它是什么？ 与TDD有何不同？ 我了解BDD的重点是规范，而不是测试。它与域驱动设计链接(您不喜欢这些* DD首字母缩写词吗？)。 它与编写用户案例的特定方法(包括高级测试)相关联。汤姆·十·蒂(Tom十Thij)
(在他的文章中，Tom继续在Ruby中直接执行此测试规范。) BDD的教皇是Dan North。您可以在他的BDD简介文章中找到很好的介绍。 您将在此视频中找到BDD和TDD的比较。杰里米·米勒(Jeremy D. Miller)也认为BDD是"正确的TDD" 2013年3月25日更新 上面的视频已经消失了一段时间。这是Llewellyn Falco的最新作品，BDD vs TDD(解释)。我认为他的解释清楚明确。 对我而言，BDD和TDD之间的主要区别在于重点和措辞。言语对于传达您的意图很重要。 TDD将重点放在测试上。并且由于在"旧瀑布世界"中进行测试是在实施之后进行的，因此这种思维方式会导致错误的理解和行为。 BDD专注于行为和规范，因此瀑布般的思维分散了注意力。因此，BDD更容易理解为设计实践，而不是测试实践。 BDD似乎有两种类型。 第一个是Dan North讨论的原始样式，它导致了xBehave样式框架的创建。对我而言，这种样式主要适用于针对领域对象的验收测试或规范。 第二种风格是Dave Astels所流行的，对我而言，这是TDD的一种新形式，它具有一定的优势。它着重于行为而不是测试以及小型测试类，以期使每个规范(测试)方法基本上只有一行。这种样式适合所有级别的测试，并且可以使用任何现有的单元测试框架来完成，尽管较新的框架(xSpec样式)帮助将行为集中于行为而不是测试。 还有一个BDD组，您可能会发现它有用： http://groups.google.com/group/behaviordrivendevelopment/ 测试驱动开发是一种测试优先的软件开发方法，这意味着它需要先编写测试代码，然后再编写将要测试的实际代码。用肯特·贝克的话来说： 好。
在弄清楚如何编写一小段代码之后，现在，我们不仅要编写代码，还希望获得即时反馈并练习"稍作编码，稍作测试，稍作编码，再测试"。因此，我们立即为其编写了一个测试。 好。 因此，TDD是程序员用来生成有效代码的低级技术方法。 好。 行为驱动开发是一种基于TDD创建的方法，但后来演变成一个过程，该过程不仅涉及程序员和测试人员，而且涉及整个团队以及所有重要的利益相关者，包括技术人员和非技术人员。 BDD从TDD不能很好回答的几个简单问题开始：我应该写多少个测试？我应该实际测试什么，我不应该测试什么？实际上，我编写的哪些测试对业务或产品的整体质量很重要，而哪些只是我的过度设计？ 好。 如您所见，此类问题需要技术与业务之间的协作。业务利益相关者和领域专家通常可以告诉工程师什么样的测试听起来很有用，但前提是这些测试是涉及重要业务方面的高级测试。 BDD将此类似业务的测试称为"示例"，如"告诉我此功能应如何正确运行的示例"，并为低级别的技术检查(例如数据验证或测试API集成)保留了"测试"一词。重要的是，尽管测试只能由程序员和测试人员创建，但是示例可以由整个交付团队(由设计师，分析师等)收集和分析。 好。 一句话，到目前为止，我发现的BDD最佳定义之一是BDD的意思是"与领域专家进行对话，并使用示例来获得对所需行为的共同理解并发现未知物。"发现部分非常重要。 。随着交付团队收集更多示例，他们开始越来越了解业务领域，因此他们减少了对他们必须处理的产品某些方面的不确定性。随着不确定性的降低，交付团队的创造力和自主权也会增加。例如，他们现在可以开始建议自己的示例，这些示例由于缺乏技术专业知识而使业务用户认为不可能。 好。 现在，与业务和领域专家进行对话听起来很不错，但是我们都知道在实践中通常会如此。我以程序员的身份开始了技术之旅。作为程序员，我们被教导编写代码-算法，设计模式，抽象。或者，如果您是设计师，就会被教导设计—组织信息并创建漂亮的界面。但是，当我们获得入门级职位时，我们的雇主期望我们"为客户创造价值"。在这些客户中，例如可以是……银行。但是我几乎对银行一无所知-除了如何有效地减少我的帐户余额。因此，我必须以某种方式将对我的期望转换为代码...如果我想提供任何价值，就必须在银行业和我的技术专长之间架起一座桥梁。 BDD帮助我在交付团队和领域专家之间的稳定沟通的稳定基础上架起了一座桥梁。 好。 学到更多 好。 如果您想了解有关BDD的更多信息，我写了一本书。"撰写出色的规范"探讨了分析需求的技巧，将帮助您学习如何构建出色的BDD流程并将示例用作该流程的核心部分。这本书讨论了无处不在的语言，收集了示例，并从示例中创建了所谓的可执行规范(自动测试)，这些技术可帮助BDD团队按时，按预算提供出色的软件。 好。 如果您有兴趣购买"书写规范"，可以使用促销代码39nicieja2节省39％:) 好。 好。 我已经对BDD方法进行了一些试验，但我的过早结论是BDD非常适合用例实现，但不适用于底层细节。 TDD仍处于这一水平。 BDD也用作通信工具。目的是编写领域专家可以理解的可执行规范。 考虑将TDD的主要好处是设计。它应该称为测试驱动设计。 BDD是TDD的子集，称为行为驱动设计。 现在考虑一种流行的TDD实现-单元测试。单元测试中的单元通常是逻辑的一点，这是您可以做的最小工作单元。 当您以功能性方式将这些单元组合在一起以描述机器所需的行为时，您需要了解要描述的机器行为。行为驱动设计专注于验证实施者对用例/需求/任何事物的理解，并验证每个功能的实现。通常，BDD和TDD的主要目的是通知设计，第二个目的是检验实现的正确性，尤其是当实现更改时。正确的BDD涉及biz和dev(以及qa)，而单元测试(可能被错误地视为TDD而非一种TDD类型)通常是在dev筒仓中完成的。 我还要补充一点，BDD测试可以满足生活要求。 与TDD相比，根据我在BDD中的最新知识，BDD专注于指定接下来将要发生的事情，而TDD则专注于设置一组条件，然后查看输出。 在我看来，BDD的范围更广。这几乎暗示着使用了TDD，BDD是一种可简化的方法，它收集了信息和要求，以使用TDD实践来确保快速反馈。 行为驱动开发似乎更关注开发人员之间以及开发人员和测试人员之间的交互和通信。 维基百科文章有一个解释： 行为驱动的发展 虽然我自己没有练习BDD。
简而言之，TDD和BDD之间存在主要差异 测试驱动开发(TDD)和行为驱动开发(BDD)之间的区别
这是快速快照：
BDD在很大程度上是TDD正确完成的。但是，BDD提供了额外的价值。这是一个链接： BDD不仅仅是"正确完成TDD" TDD和BDD之间没有区别。除了可以更好地阅读测试，而且可以将其用作要求。如果用与编写BDD测试相同的词来编写需求，那么您可以来自客户，定义了一些准备编写代码的测试。 |
