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

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

44049 次浏览
小开

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

维基百科上的文章解释说:

行为驱动开发

虽然我自己没有练习 BDD。

小开

在我看来，BDD 是一个更广泛的范围。它几乎意味着 TDD 被使用，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 的教皇是 Dan North。你会在他的 介绍 BDD文章中找到一个很好的介绍。

您将在此 视频中找到 BDD 和 TDD 的比较。还有一个关于 BDD 的意见，作为“ TDD 做正确”的 Jeremy D. Miller

2013年3月25日更新

上面的视频已经丢失一段时间了。这是卢埃林 · 法尔科(Llewellyn Falco)最近的作品。我认为他的解释清楚而中肯。

小开

我已经对 BDD 方法进行了一些实验，并且得出了一个不成熟的结论: BDD 非常适合用例实现，但不适合基础细节。TDD 仍然在那个水平上摇滚。

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

小开

对我来说，BDD 和 TDD 的主要区别在于重点和措辞，而言辞对于沟通你的意图很重要。

TDD 将重点放在测试上。由于在“旧瀑布世界”测试中，实现之后才是测试，因此这种心态会导致错误的理解和行为。

BDD 将注意力集中在行为和规范上，因此瀑布思维会分散注意力。因此，BDD 更容易理解为设计实践，而不是测试实践。

小开

似乎有两种类型的 BDD。

第一个是 Dan North 讨论的原始样式，它导致了 xBehave 样式框架的创建。对我来说，这种风格主要适用于针对领域对象的验收测试或规范。

第二种风格是 DaveAstels 推广的，对我来说，它是 TDD 的一种新形式，具有一些重要的好处。它关注的是行为而不是测试，还有一些小的测试类，试图达到每个规范(测试)方法基本上只有一行的程度。这种风格适合所有级别的测试，并且可以通过新的框架(xSpec 风格)使用任何现有的单元测试框架来帮助关注行为而不是测试。

还有一个 BDD 组，你可能会发现它很有用:

Http://groups.google.com/group/behaviordrivendevelopment/

小开

与 TDD 相比，我在 BDD 方面的最新知识是，BDD 侧重于指定接下来会发生什么，而 TDD 侧重于设置一组条件，然后查看输出。

小开

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

小开

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

现在考虑一个流行的 TDD 单元测试实现。单元测试中的单元通常是一个逻辑位，它是您可以创建的最小工作单元。

当您以功能性的方式将这些单元放在一起来描述机器所需的行为时，您需要理解您正在向机器描述的行为。行为驱动设计侧重于验证实现者对用例/需求/任何东西的理解，并验证每个特性的实现。BDD 和 TDD 通常服务于通知设计的重要目的和验证实现的正确性的第二个目的，特别是当它发生变化时。正确完成 BDD 涉及 biz 和 dev (以及 qa) ，而单元测试(可能被错误地视为 TDD 而不是 TDD 的一种类型)通常是在 dev 竖井中完成的。

我要补充的是，BDD 测试作为生活需求。

小开

以下是快照:

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

  • DDD 是在每个触摸代码周期之前被告知域的过程！

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

小开

测试驱动开发 是一个测试优先的程序设计方法学，这意味着它需要在编写将被测试的实际代码之前编写测试代码。用肯特 · 贝克的话说:

这里的样式是编写几行代码，然后测试 应该运行，甚至更好的是，编写一个不会运行的测试，然后编写 让它运行的代码。

在搞清楚如何编写一小段代码之后，现在，我们不再只是编写代码，而是希望得到即时的反馈，并练习“编写一点代码，进行一点测试，编写一点代码，进行一点测试。”所以我们立即为它编写了一个测试。

因此 TDD 是一种低级的技术方法，程序员用它来生成可以工作的干净代码。

行为驱动开发 是一种基于 TDD 创建的方法，但是演变成了一个不仅仅关注程序员和测试人员的过程，而是关注整个团队和所有重要的涉众，无论是技术的还是非技术的。BDD 从几个 TDD 不能很好回答的简单问题开始: 我应该编写多少测试？我实际上应该测试什么ーー什么是我不应该测试的？我编写的哪些测试实际上对业务或产品的整体质量非常重要，哪些只是我的过度设计？

正如您所看到的，这样的问题需要技术和业务之间的协作。业务利益相关者和领域专家通常可以告诉工程师什么样的测试听起来有用，但前提是这些测试是处理重要业务方面的高级测试。BDD 将这种类似业务的测试称为“示例”，比如“告诉我这个特性应该如何正确运行的示例”，并将“测试”这个词保留给低层次的技术检查，比如数据验证或测试 API 集成。重要的是，虽然 测试只能由程序员和测试人员创建，但是 例子可以由整个交付团队ーー设计人员、分析人员等ーー收集和分析。

在一个句子中，BDD 的最好的定义之一，我已经 找到了到目前为止是，BDD 是关于“与领域专家进行对话，并使用例子，以获得共同理解所需的行为和发现未知。”发现的部分非常重要。随着交付团队收集更多的示例，他们开始越来越多地理解业务领域，从而减少了他们对必须处理的产品的某些方面的不确定性。随着不确定性的减少，交付团队的创造性和自主性增加。例如，他们现在可以开始建议他们自己的例子，商业用户认为不可能，因为他们缺乏技术专业知识。

现在，与业务和领域专家进行对话听起来很不错，但我们都知道这通常在实践中是如何结束的。作为一名程序员，我开始了我的科技之旅。作为程序员，我们被教授 写代码ーー算法、设计模式、抽象。或者，如果你是一个设计师，你被教授 设计ー组织信息和创建漂亮的界面。但是，当我们得到入门级的工作时，我们的雇主希望我们“为客户提供价值”在这些客户中可以有，比如说... 一家银行。但我对银行业几乎一无所知ーー除了知道如何有效地减少我的账户余额。因此，我必须设法将人们对我的期望转化为代码... ... 如果我想交付任何价值，我必须在银行业务和我的技术专长之间架起一座桥梁。BDD 帮助我在交付团队和领域专家之间流畅交流的稳定基础上构建这样的桥梁。

了解更多

如果你想了解更多关于 BDD 的知识，我写了一本关于这个主题的书。译自: 美国《经济学人》杂志网站(http://www.manning.com/books/write-Great-specations? a _ aid = sbeug)原著: http://www.manning.com/books/write-Great-specials探索了分析需求的艺术，并将帮助您学习如何构建一个伟大的 BDD 过程，并将示例作为该过程的核心部分。这本书讨论了无处不在的语言，收集例子，并根据例子创建所谓的可执行规范(自动化测试) ，这些技术可以帮助 BDD 团队按时按预算交付优秀的软件。

如果你有兴趣购买“写大规格,”你可以节省39% 与促销代码 39nicieja2:)

小开

简而言之，TDD 和 BDD 之间有很大的区别 在 TDD 中，我们主要关注测试数据 在 BDD 中，我们主要关注的是项目的行为，这样任何非编程人员都可以代表该方法的标题理解代码行


提交答案