I have experimented a little with the BDD approach and my premature conclusion is that BDD is well suited to use case implementation, but not on the underlying details. TDD still rock on that level.
BDD is also used as a communication tool. The goal is to write executable specifications which can be understood by the domain experts.
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
I understand BDD to be more about specification than testing. It is linked to Domain Driven Design (don't you love these *DD acronyms?).
It is linked with a certain way to write user stories, including high-level tests. An example by 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
(In his article, Tom goes on to directly execute this test specification in Ruby.)
You will find a comparison of BDD and TDD in this video. Also an opinion about BDD as "TDD done right" by Jeremy D. Miller
March 25, 2013 update
The video above has been missing for a while. Here is a recent one by Llewellyn Falco, BDD vs TDD (explained). I find his explanation clear and to the point.
The first is the original style that Dan North discusses and which caused the creation of the xBehave style frameworks. To me this style is primarily applicable for acceptance testing or specifications against domain objects.
The second style is what Dave Astels popularised and which, to me, is a new form of TDD which has some serious benefits. It focuses on behavior rather than testing and also small test classes, trying to get to the point where you basically have one line per specification (test) method. This style suits all levels of testing and can be done using any existing unit testing framework though newer frameworks (xSpec style) help focus one the behavior rather than testing.
There is also a BDD group which you might find useful:
To me primary difference between BDD and TDD is focus and wording. And words are important for communicating your intent.
TDD directs focus on testing. And since in "old waterfall world" tests come after implementation, then this mindset leads to wrong understanding and behaviour.
BDD directs focus on behaviour and specification, and so waterfall minds are distracted. So BDD is more easily understood as design practice and not as testing practice.
如果您有兴趣购买“Writing Great Specifices”，您可以使用促销代码 39nicieja2 节省 39% :)
Test-Driven Development is a test-first software development methodology, which means that it requires writing test code before writing the actual code that will be tested. In Kent Beck’s words:
The style here is to write a few lines of code, then a test that should run, or even better, to write a test that won't run, then write the code that will make it run.
After figuring out how to write one small piece of code, now, instead of just coding on, we want to get immediate feedback and practice "code a little, test a little, code a little, test a little." So we immediately write a test for it.
So TDD is a low-level, technical methodology that programmers use to produce clean code that works.
Behaviour-Driven Development is a methodology that was created based on TDD, but evolved into a process that doesn’t concern only programmers and testers, but instead deals with the entire team and all important stakeholders, technical and non-technical. BDD started out of a few simple questions that TDD doesn’t answer well: how much tests should I write? What should I actually test—and what shouldn’t I? Which of the tests I write will be in fact important to the business or to the overall quality of the product, and which are just my over-engineering?
As you can see, such questions require collaboration between technology and business. Business stakeholders and domain experts often can tell engineers what kind of tests sound like they would be useful—but only if the tests are high-level tests that deal with important business aspects. BDD calls such business-like tests “examples,” as in “tell me an example of how this feature should behave correctly,” and reserves the word “test” for low-level, technical checks such as data validation or testing API integrations. The important part is that while tests can only be created by programmers and testers, examples can be collected and analysed by the entire delivery team—by designers, analysts, and so on.
In a sentence, one of the best definitions of BDD I have found so far is that BDD is about “having conversations with domain experts and using examples to gain a shared understanding of the desired behaviour and discover unknowns.” The discovery part is very important. As the delivery team collects more examples, they start to understand the business domain more and more and thus they reduce their uncertainty about some aspects of the product they have to deal with. As uncertainty decreases, creativity and autonomy of the delivery team increase. For instance, they can now start suggesting their own examples that the business users didn’t think were possible because of their lack of tech expertise.
Now, having conversations with the business and domain experts sounds great, but we all know how that often ends up in practice. I started my journey with tech as a programmer. As programmers, we are taught to write code—algorithms, design patterns, abstractions. Or, if you are a designer, you are taught to design—organize information and create beautiful interfaces. But when we get our entry-level jobs, our employers expect us to "deliver value to the clients." And among those clients can be, for example... a bank. But I could know next to nothing about banking—except how to efficiently decrease my account balance. So I would have to somehow translate what is expected of me into code... I would have to build a bridge between banking and my technical expertise if I want to deliver any value. BDD helps me build such a bridge on a stable foundation of fluid communication between the delivery team and the domain experts.
Learn more
If you want to read more about BDD, I wrote a book on the subject. “Writing Great Specifications” explores the art of analysing requirements and will help you learn how to build a great BDD process and use examples as a core part of that process. The book talks about the ubiquitous language, collecting examples, and creating so-called executable specifications (automated tests) out of the examples—techniques that help BDD teams deliver great software on time and on budget.
If you are interested in buying “Writing Great Specifications,” you can save 39% with the promo code 39nicieja2 :)
With my latest knowledge in BDD when compared to TDD, BDD focuses on specifying what will happen next, whereas TDD focuses on setting up a set of conditions and then looking at the output.
Consider the primary benefit of TDD to be design. It should be called Test Driven Design. BDD is a subset of TDD, call it Behaviour Driven Design.
Now consider a popular implementation of TDD - Unit Testing. The Units in Unit Testing are typically one bit of logic that is the smallest unit of work you can make.
When you put those Units together in a functional way to describe the desired Behaviour to the machines, you need to understand the Behaviour you are describing to the machine. Behaviour Driven Design focuses on verifying the implementers' understanding of the Use Cases/Requirements/Whatever and verifies the implementation of each feature. BDD and TDD in general serves the important purpose of informing design and the second purpose of verifying the correctness of the implementation especially when it changes. BDD done right involves biz and dev (and qa), whereas Unit Testing (possibly incorrectly viewed as TDD rather than one type of TDD) is typically done in the dev silo.
I would add that BDD tests serve as living requirements.
It seems to me that BDD is a broader scope. It almost implies TDD is used, that BDD is the encompassing methodology that gathers the information and requirements for using, among other things, TDD practices to ensure rapid feedback.
In short there is major difference between TDD and BDD In TDD we are majorly focused on Test data In BDD our main focus is on behavior of the project so that any non - programming person can understand the line of code on the behalf of the title of that method
There is no difference between TDD and BDD. except you can read your tests better, and you can use them as requirements. If you write your requirements with the same words as you write BDD tests then you can come from your client with some of your tests defined ready to write code.
发布评论
评论（12）
我对 BDD 方法进行了一些实验，我的过早结论是 BDD 非常适合用例实现，但不适用于底层细节。 TDD 仍然处于这个水平。
BDD 也用作通信工具。 目标是编写领域专家可以理解的可执行规范。
I have experimented a little with the BDD approach and my premature conclusion is that BDD is well suited to use case implementation, but not on the underlying details. TDD still rock on that level.
BDD is also used as a communication tool. The goal is to write executable specifications which can be understood by the domain experts.
我认为 BDD 更多的是关于规范，而不是测试。 它与领域驱动设计相关（您不喜欢这些 *DD 缩写吗？）。
它与编写用户故事的某种方式相关联，包括高级测试。 汤姆十的示例Thij：
（Tom 在他的文章中继续直接在 Ruby 中执行此测试规范。）
BDD 的教皇是 Dan北。 您可以在他的BDD 简介文章中找到精彩的介绍。
您可以在此视频中找到 BDD 和 TDD 的比较。 Jeremy D. Miller
2013 年 3 月 25 日更新
上面的视频已经丢失了一段时间。 这是 Llewellyn Falco 最近发表的一篇文章，BDD 与 TDD（解释）。 我发现他的解释清晰且切题。
I understand BDD to be more about specification than testing. It is linked to Domain Driven Design (don't you love these *DD acronyms?).
It is linked with a certain way to write user stories, including high-level tests. An example by Tom ten Thij:
(In his article, Tom goes on to directly execute this test specification in Ruby.)
The pope of BDD is Dan North. You'll find a great introduction in his Introducing BDD article.
You will find a comparison of BDD and TDD in this video. Also an opinion about BDD as "TDD done right" by Jeremy D. Miller
March 25, 2013 update
The video above has been missing for a while. Here is a recent one by Llewellyn Falco, BDD vs TDD (explained). I find his explanation clear and to the point.
BDD 似乎有两种类型。
第一个是 Dan North 讨论的原始风格，它导致了 xBehave 风格框架的创建。 对我来说，这种风格主要适用于针对域对象的验收测试或规范。
第二种风格是 Dave Astels 推广的风格，对我来说，这是 TDD 的一种新形式，它有一些重大的好处。 它侧重于行为而不是测试以及小型测试类，试图达到每个规范（测试）方法基本上只有一行的程度。 这种风格适合所有级别的测试，并且可以使用任何现有的单元测试框架来完成，尽管较新的框架（xSpec 风格）有助于关注行为而不是测试。
还有一个 BDD 小组，您可能会觉得有用：
http://groups.google.com/group/行为驱动开发/
There seem to be two types of BDD.
The first is the original style that Dan North discusses and which caused the creation of the xBehave style frameworks. To me this style is primarily applicable for acceptance testing or specifications against domain objects.
The second style is what Dave Astels popularised and which, to me, is a new form of TDD which has some serious benefits. It focuses on behavior rather than testing and also small test classes, trying to get to the point where you basically have one line per specification (test) method. This style suits all levels of testing and can be done using any existing unit testing framework though newer frameworks (xSpec style) help focus one the behavior rather than testing.
There is also a BDD group which you might find useful:
http://groups.google.com/group/behaviordrivendevelopment/
对我来说，BDD 和 TDD 之间的主要区别在于焦点和措辞。 言语对于传达你的意图很重要。
TDD 将重点放在测试上。 由于在“旧瀑布世界”中测试是在实施之后进行的，因此这种心态会导致错误的理解和行为。
BDD 将注意力集中在行为和规范上，因此瀑布思维会分散注意力。 因此，BDD 更容易理解为设计实践，而不是测试实践。
To me primary difference between BDD and TDD is focus and wording. And words are important for communicating your intent.
TDD directs focus on testing. And since in "old waterfall world" tests come after implementation, then this mindset leads to wrong understanding and behaviour.
BDD directs focus on behaviour and specification, and so waterfall minds are distracted. So BDD is more easily understood as design practice and not as testing practice.
测试驱动开发是一种测试优先的软件开发方法，这意味着它需要在编写要测试的实际代码之前编写测试代码。 用肯特·贝克的话来说：
在弄清楚如何编写一小段代码之后，现在我们不只是继续编码，而是希望获得即时反馈并练习“编码一点，测试一点，编码一点，测试一点”。 所以我们立即为其编写一个测试。
因此，TDD 是一种低级技术方法，程序员可以用它来生成干净、有效的代码。
行为驱动开发是一种基于 TDD 创建的方法，但演变成一个过程，它不仅仅涉及程序员和测试人员，而是涉及整个团队以及所有重要的利益相关者、技术和人员。非技术。 BDD 始于一些 TDD 无法很好回答的简单问题：我应该编写多少测试？ 我实际上应该测试什么，不应该测试什么？ 我编写的哪些测试实际上对业务或产品的整体质量很重要，哪些只是我的过度设计？
正如您所看到的，这些问题需要技术和业务之间的协作。 业务利益相关者和领域专家通常可以告诉工程师什么样的测试听起来有用，但前提是这些测试是处理重要业务方面的高级测试。 BDD 将此类业务测试称为“示例”，例如“告诉我一个该功能应如何正确运行的示例”，并保留“测试”一词用于低级技术检查，例如数据验证或测试 API 集成。 重要的是，虽然测试只能由程序员和测试人员创建，示例可以由整个交付团队（设计师、分析师等）收集和分析。
用一句话来说，到目前为止我发现的 BDD 最佳定义之一是BDD 是关于“与领域专家进行对话并使用示例来获得对所需行为的共同理解并发现未知数”。 发现部分非常重要。 随着交付团队收集更多示例，他们开始越来越了解业务领域，从而减少了他们必须处理的产品某些方面的不确定性。 随着不确定性的减少，交付团队的创造力和自主权就会增加。 例如，他们现在可以开始提出自己的示例，而业务用户由于缺乏技术专业知识而认为这些示例是不可能的。
现在，与业务和领域专家进行对话听起来很棒，但我们都知道这在实践中通常会如何结束。 我作为一名程序员开始了我的科技之旅。 作为程序员，我们被教导如何编写代码——算法、设计模式、抽象。 或者，如果您是一名设计师，您会被教导如何设计——组织信息并创建漂亮的界面。 但当我们获得入门级工作时，雇主希望我们“为客户提供价值”。 例如，这些客户可以是……银行。 但我对银行业务几乎一无所知——除了如何有效地减少我的账户余额。 因此，我必须以某种方式将对我的期望转化为代码……如果我想提供任何价值，我就必须在银行业和我的技术专业知识之间建立一座桥梁。 BDD 帮助我在交付团队和领域专家之间的流畅沟通的稳定基础上建立了这样一座桥梁。
了解更多
如果您想了解有关 BDD 的更多信息，我写了一本关于该主题的书。 “编写出色的规范”探索分析需求的艺术，并将帮助您学习如何构建出色的 BDD 流程并使用示例作为该流程的核心部分。 这本书讨论了无处不在的语言、收集示例以及根据示例创建所谓的可执行规范（自动化测试），这些技术可以帮助 BDD 团队按时、按预算交付出色的软件。
如果您有兴趣购买“Writing Great Specifices”，您可以使用促销代码 39nicieja2 节省 39% :)
Test-Driven Development is a test-first software development methodology, which means that it requires writing test code before writing the actual code that will be tested. In Kent Beck’s words:
After figuring out how to write one small piece of code, now, instead of just coding on, we want to get immediate feedback and practice "code a little, test a little, code a little, test a little." So we immediately write a test for it.
So TDD is a low-level, technical methodology that programmers use to produce clean code that works.
Behaviour-Driven Development is a methodology that was created based on TDD, but evolved into a process that doesn’t concern only programmers and testers, but instead deals with the entire team and all important stakeholders, technical and non-technical. BDD started out of a few simple questions that TDD doesn’t answer well: how much tests should I write? What should I actually test—and what shouldn’t I? Which of the tests I write will be in fact important to the business or to the overall quality of the product, and which are just my over-engineering?
As you can see, such questions require collaboration between technology and business. Business stakeholders and domain experts often can tell engineers what kind of tests sound like they would be useful—but only if the tests are high-level tests that deal with important business aspects. BDD calls such business-like tests “examples,” as in “tell me an example of how this feature should behave correctly,” and reserves the word “test” for low-level, technical checks such as data validation or testing API integrations. The important part is that while tests can only be created by programmers and testers, examples can be collected and analysed by the entire delivery team—by designers, analysts, and so on.
In a sentence, one of the best definitions of BDD I have found so far is that BDD is about “having conversations with domain experts and using examples to gain a shared understanding of the desired behaviour and discover unknowns.” The discovery part is very important. As the delivery team collects more examples, they start to understand the business domain more and more and thus they reduce their uncertainty about some aspects of the product they have to deal with. As uncertainty decreases, creativity and autonomy of the delivery team increase. For instance, they can now start suggesting their own examples that the business users didn’t think were possible because of their lack of tech expertise.
Now, having conversations with the business and domain experts sounds great, but we all know how that often ends up in practice. I started my journey with tech as a programmer. As programmers, we are taught to write code—algorithms, design patterns, abstractions. Or, if you are a designer, you are taught to design—organize information and create beautiful interfaces. But when we get our entry-level jobs, our employers expect us to "deliver value to the clients." And among those clients can be, for example... a bank. But I could know next to nothing about banking—except how to efficiently decrease my account balance. So I would have to somehow translate what is expected of me into code... I would have to build a bridge between banking and my technical expertise if I want to deliver any value. BDD helps me build such a bridge on a stable foundation of fluid communication between the delivery team and the domain experts.
Learn more
If you want to read more about BDD, I wrote a book on the subject. “Writing Great Specifications” explores the art of analysing requirements and will help you learn how to build a great BDD process and use examples as a core part of that process. The book talks about the ubiquitous language, collecting examples, and creating so-called executable specifications (automated tests) out of the examples—techniques that help BDD teams deliver great software on time and on budget.
If you are interested in buying “Writing Great Specifications,” you can save 39% with the promo code 39nicieja2 :)
行为驱动开发似乎更关注开发人员之间以及开发人员和测试人员之间的交互和沟通。
维基百科文章有一个解释：
行为驱动开发
不过我自己并没有实践 BDD。
Behaviour Driven Development seems to focus more on the interaction and communication between Developers and also between Developers and testers.
The Wikipedia Article has an explanation:
Behavior-driven development
Not practicing BDD myself though.
根据我对 BDD 的最新了解，与 TDD 相比，BDD 侧重于指定接下来会发生什么，而 TDD 侧重于设置一组条件，然后查看输出。
With my latest knowledge in BDD when compared to TDD, BDD focuses on specifying what will happen next, whereas TDD focuses on setting up a set of conditions and then looking at the output.
考虑 TDD 的主要好处是设计。 应该叫测试驱动设计。 BDD 是 TDD 的子集，称为行为驱动设计。
现在考虑 TDD 的一种流行实现——单元测试。 单元测试中的单元通常是一点逻辑，它是您可以进行的最小工作单元。
当您以功能方式将这些单元组合在一起以向机器描述所需的行为时，您需要了解您向机器描述的行为。 行为驱动设计侧重于验证实现者对用例/需求/任何内容的理解，并验证每个功能的实现。 BDD 和 TDD 通常服务于为设计提供信息的重要目的，以及验证实现的正确性（尤其是在实现发生变化时）的第二个目的。 正确完成的 BDD 涉及业务和开发（以及质量保证），而单元测试（可能被错误地视为 TDD，而不是 TDD 的一种类型）通常在开发竖井中完成。
我想补充一点，BDD 测试是生活必需品。
Consider the primary benefit of TDD to be design. It should be called Test Driven Design. BDD is a subset of TDD, call it Behaviour Driven Design.
Now consider a popular implementation of TDD - Unit Testing. The Units in Unit Testing are typically one bit of logic that is the smallest unit of work you can make.
When you put those Units together in a functional way to describe the desired Behaviour to the machines, you need to understand the Behaviour you are describing to the machine. Behaviour Driven Design focuses on verifying the implementers' understanding of the Use Cases/Requirements/Whatever and verifies the implementation of each feature. BDD and TDD in general serves the important purpose of informing design and the second purpose of verifying the correctness of the implementation especially when it changes. BDD done right involves biz and dev (and qa), whereas Unit Testing (possibly incorrectly viewed as TDD rather than one type of TDD) is typically done in the dev silo.
I would add that BDD tests serve as living requirements.
在我看来，BDD的范围更广。 这几乎意味着使用 TDD，BDD 是一种包罗万象的方法，它收集使用 TDD 实践的信息和要求，以确保快速反馈。
It seems to me that BDD is a broader scope. It almost implies TDD is used, that BDD is the encompassing methodology that gathers the information and requirements for using, among other things, TDD practices to ensure rapid feedback.
简而言之，TDD 和 BDD 之间存在重大区别
在 TDD 中，我们主要关注测试数据
在BDD中，我们主要关注的是项目的行为，以便任何非编程人员都可以理解代表该方法标题的代码行。
In short there is major difference between TDD and BDD
In TDD we are majorly focused on Test data
In BDD our main focus is on behavior of the project so that any non - programming person can understand the line of code on the behalf of the title of that method
TDD 和 BDD 之间没有区别。 除了你可以更好地阅读你的测试，并且你可以将它们用作需求。 如果您使用与编写 BDD 测试相同的文字来编写需求，那么您可以从客户处获得一些已定义的测试，以准备编写代码。
There is no difference between TDD and BDD. except you can read your tests better, and you can use them as requirements. If you write your requirements with the same words as you write BDD tests then you can come from your client with some of your tests defined ready to write code.
这是快速快照：
Here's the quick snapshot: