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

StackOverflow https://stackoverflow.com/questions/2509

  •  08-06-2019
  •  | 
  •  

题

过去几年，测试驱动开发在 .NET 社区中风靡一时。最近，我在 ALT.NET 社区中听到了有关 BDD 的抱怨。它是什么？它与 TDD 有何不同？

有帮助吗？

解决方案

我对 BDD 的理解更多的是 规格 比 测试. 。它与领域驱动设计相关（您不喜欢这些 *DD 缩写吗？）。

它与编写用户故事的某种方式相关联，包括高级测试。一个例子 汤姆·十·泰吉:

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

（在 Tom 的文章中，继续在 Ruby 中直接执行此测试规范。）

BDD的教皇是 丹·诺斯. 。你会在他的文章中找到精彩的介绍 介绍 BDD 文章。

你会发现 BDD 和 TDD 的比较 视频. 。还有一个关于 BDD 的观点是“TDD 做对了” 杰里米·D.磨坊主

2013 年 3 月 25 日更新

上面的视频已经丢失了一段时间。这是卢埃林·法尔科 (Llewellyn Falco) 最近的一篇文章， BDD 与 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 团队按时、按预算交付出色的软件。

如果您有兴趣购买“编写出色的规范”， 您可以节省 39% 使用促销代码 39nicieja2 :)

我对 BDD 方法进行了一些实验，我的过早结论是 BDD 非常适合用例实现，但不适用于底层细节。TDD 仍然处于这个水平。

BDD 也用作通信工具。目标是编写领域专家可以理解的可执行规范。

在我看来，BDD的范围更广。这几乎意味着使用了 TDD，BDD 是一种涵盖的方法，它收集使用 TDD 实践的信息和要求，以确保快速反馈。

根据我对 BDD 的最新了解，与 TDD 相比，BDD 侧重于指定接下来会发生什么，而 TDD 侧重于设置一组条件，然后查看输出。

行为驱动开发似乎更关注开发人员之间以及开发人员和测试人员之间的交互和沟通。

维基百科文章有一个解释：

行为驱动的发展

不过我自己并没有练习 BDD。

考虑 TDD 的主要好处是设计。应该叫测试驱动设计。BDD 是 TDD 的子集，称为行为驱动设计。

现在考虑 TDD 的一种流行实现——单元测试。单元测试中的单元通常是一点逻辑，它是您可以进行的最小工作单元。

当您以功能方式将这些单元组合在一起以向机器描述所需的行为时，您需要了解您向机器描述的行为。行为驱动设计侧重于验证实现者对用例/需求/任何内容的理解，并验证每个功能的实现。BDD 和 TDD 通常服务于为设计提供信息的重要目的，以及验证实现的正确性（尤其是在实现发生变化时）的第二个目的。正确完成的 BDD 涉及业务和开发（以及质量保证），而单元测试（可能被错误地视为 TDD，而不是 TDD 的一种类型）通常在开发竖井中完成。

我想补充一点，BDD 测试是生活必需品。

BDD 很大程度上是正确执行的 TDD。然而，BDD 还提供了额外的价值。这是一个链接：

BDD 不仅仅是“正确执行 TDD”

这是快速快照：

  • TDD 只是在编写代码之前测试代码的过程！

  • DDD 是在每次接触代码的循环之前了解域的过程！

  • BDD 是 TDD 的一种实现，它引入了 DDD 的某些方面！

希望有帮助！

测试驱动开发（TDD）和行为驱动开发（BDD）之间的区别

  • BDD 关注的是系统的行为方面而不是系统本身
    TDD 关注的系统的实现方面。

  • BDD 可以更清晰地理解系统应该做什么
    从开发商和客户的角度来看。仅限时分双工
    让开发人员了解系统应该做什么。

  • BDD允许开发人员和客户都可以在系统源代码中包含的需求分析共同努力。

TDD 和 BDD 之间没有区别。除了你可以更好地阅读你的测试，并且你可以将它们用作需求。如果您使用与编写 BDD 测试相同的文字来编写需求，那么您可以从客户那里获得一些已定义的测试，以准备编写代码。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top