TDD和BDD主要有什么区别？

Question

TDD和BDD主要有什么区别？

unit-testingtddbdd

135

测试驱动开发（Test Driven Development）在.NET社区已经风靡了几年。最近，我听到ALT.NET社区对行为驱动开发（BDD）的抱怨声。那么什么是BDD？它与TDD有何不同？

- NotMyself

2

请参见http://programmers.stackexchange.com/q/135218/76176。这个问题更适合在那里讨论。 - Evan Carroll

TDD 适用于微测试。BDD 适用于需求或宏测试。请收听第1至8集关于测试金字塔的内容，它将解释这些级别：https://agilenoir.biz/series/agile-thoughts/ - Lance Kind

12个回答

16

对我来说，BDD和TDD的主要区别在于焦点和措辞。而单词对于传达您的意图非常重要。

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

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

- Jippo

3

TDD与“瀑布”式软件设计生命周期没有任何关系。如果有的话，TDD是与SDLC无关的。TDD的目标是编写最少量的代码以使测试通过。从某种意义上说，测试成为了代码需要遵循的技术规范。 - Gavin Baumanis

2

TDD是“先测试”，并且可以与敏捷开发非常配合。这不准确。 - Terrance

13

似乎有两种BDD。

第一种是Dan North讨论的原始风格，也引起了xBehave样式框架的创建。对我来说，这种风格主要适用于验收测试或对域对象进行规范。

第二种风格是Dave Astels流行的新形式TDD，它具有一些严重的好处。它专注于行为而不是测试，并且采用小型测试类，试图达到基本上每个规范（测试）方法只有一行的程度。这种风格适用于所有级别的测试，并且可以使用任何现有的单元测试框架进行，尽管较新的框架（xSpec样式）帮助集中精力于行为而不是测试。

还有一个BDD组，你可能会觉得有用：

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

- Colin Jack

8

测试驱动开发是一种先写测试代码，再编写实际代码进行测试的软件开发方法。用肯特·贝克的话来说：

这里的风格是写几行代码，然后写一个应该运行的测试，或者更好的是，编写一个不能运行的测试，然后编写使其运行的代码。

在弄清楚如何编写一小段代码后，现在，我们不仅要编码，还要获得即时反馈并练习“少量编码，少量测试，少量编码，少量测试”。因此，我们立即为其编写一个测试。

因此，TDD是程序员用来生成可靠代码的低级技术方法。

行为驱动开发（BDD）是一种基于TDD的方法论，但已经演变成一个不仅涉及程序员和测试人员，而且涉及整个团队和所有重要的利益相关者（技术和非技术）。BDD起源于几个简单的问题，这些问题TDD无法很好地回答：我应该编写多少测试？我应该测试什么——以及我不应该测试什么？我编写的哪些测试对业务或产品的整体质量实际上很重要，哪些只是我的过度工程？

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

简单来说，我找到的有关BDD最好的定义之一是“与领域专家进行对话，并使用示例来获得对所需行为和发现未知事物的共同理解。” 发现部分非常重要。随着交付团队收集更多的示例，他们开始越来越了解业务领域，因此他们减少了对产品某些方面的不确定性。随着不确定性的减少，交付团队的创造力和自主权也增加了。例如，他们现在可以开始提出自己的示例，而业务用户认为这些示例不可能实现是因为他们缺乏技术专业知识。

现在，与业务和领域专家进行对话听起来很不错，但我们都知道实践中通常会怎样。我作为一名程序员开始我的技术之旅。作为程序员，我们被教导编写代码-算法、设计模式、抽象。或者，如果你是设计师，你被教导设计-组织信息并创建漂亮的界面。但是当我们得到入门级工作时，我们的雇主期望我们“为客户提供价值”。而其中的客户可能是银行等，但我可能对银行几乎一无所知-除了如何有效地减少我的账户余额。因此，我必须以某种方式将期望转化为代码…如果我想提供任何价值，我必须在交付团队和领域专家之间建立这样一座桥梁。BDD可以帮助我建立这样一个基于流畅沟通的稳定基础上的桥梁。 了解更多 如果您想了解更多关于BDD的内容，我写了一本书。“编写优秀的规格说明” 探讨了分析需求的艺术，并将帮助您学习如何构建一个出色的BDD过程以及将示例作为该过程的核心部分。该书介绍了普遍语言、收集示例和创建所谓的可执行规格说明（自动化测试）等技术，这些技术有助于BDD团队按时按预算交付出色的软件。

如果您有兴趣购买“编写优秀的规格说明”，使用促销代码39nicieja2可以节省39% :)

- thion

6

我曾尝试过BDD方法，初步结论是，BDD非常适合用例实现，但不适用于底层详细信息。在这个层面上，TDD仍然很出色。

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

- Thomas Eyde

2

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

现在考虑TDD的一个流行实现——单元测试。单元测试中的单元通常是一小段逻辑，是你可以完成的最小工作单位。

当你将这些单元以功能方式组合在一起，来描述所需的行为给机器时，你需要理解你正在向机器描述的行为。行为驱动设计专注于验证实现者对用例/需求/任何内容的理解，并验证每个功能的实现。BDD和TDD总体上都具有重要的设计信息和验证实现正确性的目的，特别是当它发生变化时。正确执行BDD需要业务、开发人员（和质量保证），而单元测试（可能被错误地视为TDD而不是TDD的一种类型）通常在开发人员的独立环境中完成。

我想补充说明的是，BDD测试作为活的需求。

- phil v

2

最新的BDD相对于TDD而言，BDD专注于指定接下来会发生什么，而TDD则专注于设置一组条件并查看输出。

- Uma Mahesh Varma

2

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

维基百科的文章有解释：

行为驱动开发

我个人并没有实践过BDD。

- Michael Stum

2

在我看来，BDD的范围更广。这几乎意味着使用TDD，BDD是一个包罗万象的方法论，收集使用TDD实践等信息和要求，以确保快速反馈。

- palehorse

1

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

- Mihai

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Christian Lescuyer · Accepted Answer

我理解BDD更多关注规格说明而非测试。它与领域驱动设计相关联（您不喜欢这些* DD首字母缩写吗？）。

它与一种编写用户故事的特定方式相关，包括高级别测试。例如，Tom ten Thij的一个示例：

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。你可以在他的Introducing BDD文章中找到一个很好的介绍。

你可以在这个视频中找到BDD和TDD的比较。也可以看到Jeremy D. Miller对BDD作为"正确实践的TDD"的观点。

2013年3月25日更新

上面的视频已经失踪一段时间了。这里有一个最近的由Llewellyn Falco制作的BDD vs TDD(解释)视频。我认为他的讲解清晰明了。