过去几年,测试驱动开发在 .NET 社区中风靡一时。最近,我在 ALT.NET 社区中听到关于 BDD 的抱怨。它是什么?它与 TDD 有何不同?
12 回答
我理解 BDD 更多的是关于规范而不是测试。它链接到领域驱动设计(你不喜欢这些 *DD 首字母缩略词吗?)。
它与编写用户故事的某种方式相关联,包括高级测试。汤姆十 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。您会在他的介绍 BDD文章中找到很好的介绍。
您将在此视频中找到 BDD 和 TDD 的比较。Jeremy D. Miller还认为 BDD 是“正确的 TDD”
2013 年 3 月 25 日更新
上面的视频已经丢失了一段时间。这是 Llewellyn Falco 最近的一篇,BDD 与 TDD(已解释)。我觉得他的解释清楚而中肯。
对我来说,BDD 和 TDD 之间的主要区别在于焦点和措辞。言语对于传达您的意图很重要。
TDD 将重点放在测试上。而且由于在“旧瀑布世界”中测试是在实施之后进行的,因此这种心态会导致错误的理解和行为。
BDD 将注意力集中在行为和规范上,因此瀑布式思维被分散了注意力。所以 BDD 更容易理解为设计实践而不是测试实践。
似乎有两种类型的 BDD。
第一个是 Dan North 讨论的原始样式,它导致了 xBehave 样式框架的创建。对我来说,这种风格主要适用于针对域对象的验收测试或规范。
第二种风格是 Dave Astels 所推广的,对我来说,它是一种新形式的 TDD,它有一些重要的好处。它专注于行为而不是测试以及小型测试类,试图达到每个规范(测试)方法基本上只有一行的地步。这种风格适合所有级别的测试,并且可以使用任何现有的单元测试框架来完成,尽管较新的框架(xSpec 风格)有助于将注意力集中在行为而不是测试上。
还有一个 BDD 组,您可能会发现它很有用:
我对 BDD 方法进行了一些试验,我过早的结论是 BDD 非常适合用例实现,但不适用于底层细节。TDD 仍然在那个水平上摇摆不定。
BDD 也用作通信工具。目标是编写领域专家可以理解的可执行规范。
在我看来,BDD 的范围更广。这几乎意味着使用了 TDD,即 BDD 是一种包容性方法,它收集信息和要求以使用 TDD 实践以确保快速反馈。
根据我在 BDD 方面的最新知识,与 TDD 相比,BDD 侧重于指定接下来会发生什么,而 TDD 侧重于设置一组条件,然后查看输出。
考虑 TDD 的主要好处是设计。它应该被称为测试驱动设计。BDD 是 TDD 的一个子集,称为行为驱动设计。
现在考虑一个流行的 TDD 实现——单元测试。单元测试中的单元通常是一点逻辑,是您可以制作的最小工作单元。
当您以一种功能性的方式将这些单元组合在一起以向机器描述所需的行为时,您需要了解您向机器描述的行为。行为驱动设计侧重于验证实施者对用例/需求/任何内容的理解,并验证每个功能的实现。BDD 和 TDD 通常的重要目的是为设计提供信息,第二个目的是验证实现的正确性,尤其是当它发生变化时。正确完成 BDD 涉及 biz 和 dev(和 qa),而单元测试(可能被错误地视为 TDD 而不是一种 TDD)通常在 dev 孤岛中完成。
我要补充一点,BDD 测试是生活要求。
TDD和BDD之间没有区别。除非您可以更好地阅读测试,并且可以将它们用作要求。如果您使用与编写 BDD 测试相同的词来编写您的需求,那么您可以从您的客户那里获得一些已定义的测试以准备编写代码。
这是快速快照:
TDD 只是在编写代码之前测试代码的过程!
DDD 是在每次接触代码之前被告知域的过程!
BDD 是 TDD 的实现,它带来了 DDD 的某些方面!
简而言之,TDD和BDD之间有很大的区别在TDD中,我们主要关注测试数据在BDD中,我们主要关注项目的行为,以便任何非编程人员都可以理解代表标题的代码行那个方法