<p>Test Driven Development has been the rage in the .NET community for the last few years. Recently, I have heard grumblings in the ALT.NET community about BDD. What is it? What makes it different from TDD?</p>

[{'answer_id': 2515, 'author': 'Michael Stum', 'author_id': 91, 'author_profile': 'https://Stackoverflow.com/users/91', 'pm_score': 2, 'selected': False, 'text': '<p>Behaviour Driven Development seems to focus more on the interaction and communication between Developers and also between Developers and testers.</p>\n\n<p>The Wikipedia Article has an explanation:</p>\n\n<p><a href="http://en.wikipedia.org/wiki/Behavior_Driven_Development" rel="nofollow noreferrer">Behavior-driven development</a></p>\n\n<p>Not practicing BDD myself though.</p>\n'}, {'answer_id': 2520, 'author': 'palehorse', 'author_id': 312, 'author_profile': 'https://Stackoverflow.com/users/312', 'pm_score': 2, 'selected': False, 'text': '<p>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.</p>\n'}, {'answer_id': 2548, 'author': 'Christian Lescuyer', 'author_id': 341, 'author_profile': 'https://Stackoverflow.com/users/341', 'pm_score': 8, 'selected': True, 'text': '<p>I understand BDD to be more about <strong>specification</strong> than <strong>testing</strong>. It is linked to Domain Driven Design (don\'t you love these *DD acronyms?). </p>\n\n<p>It is linked with a certain way to write user stories, including high-level tests. An example by <a href="http://tomtenthij.nl/2008/1/25/rspec-plain-text-story-runner-on-a-fresh-rails-app" rel="noreferrer">Tom ten Thij</a>:</p>\n\n<pre><code>Story: User logging in\n  As a user\n  I want to login with my details\n  So that I can get access to the site\n\nScenario: User uses wrong password\n\n  Given a username \'jdoe\'\n  And a password \'letmein\'\n\n  When the user logs in with username and password\n\n  Then the login form should be shown again\n</code></pre>\n\n<p>(In his article, Tom goes on to directly execute this test specification in Ruby.)</p>\n\n<p>The pope of BDD is <a href="http://dannorth.net/" rel="noreferrer">Dan North</a>. You\'ll find a great introduction in his <a href="http://dannorth.net/introducing-bdd" rel="noreferrer">Introducing BDD</a> article.</p>\n\n<p>You will find a comparison of BDD and TDD in this <a href="http://video.google.com/videoplay?docid=8135690990081075324" rel="noreferrer">video</a>. Also an opinion about BDD as "TDD done right" by <a href="http://codebetter.com/blogs/jeremy.miller/archive/2007/09/06/bdd-tdd-and-the-other-double-d-s.aspx" rel="noreferrer">Jeremy D. Miller</a></p>\n\n<p><strong>March 25, 2013 update</strong></p>\n\n<p>The video above has been missing for a while. Here is a recent one by Llewellyn Falco, <a href="https://www.youtube.com/watch?v=mT8QDNNhExg" rel="noreferrer">BDD vs TDD (explained)</a>. I find his explanation clear and to the point.</p>\n'}, {'answer_id': 31280, 'author': 'Thomas Eyde', 'author_id': 3282, 'author_profile': 'https://Stackoverflow.com/users/3282', 'pm_score': 3, 'selected': False, 'text': '<p>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.</p>\n\n<p>BDD is also used as a communication tool. The goal is to write executable specifications which can be understood by the domain experts. </p>\n'}, {'answer_id': 50381, 'author': 'Juha Pohjalainen', 'author_id': 5240, 'author_profile': 'https://Stackoverflow.com/users/5240', 'pm_score': 4, 'selected': False, 'text': '<p>To me primary difference between BDD and TDD is focus and wording. And words are important for communicating your intent.</p>\n\n<p>TDD directs focus on testing. And since in "old waterfall world" tests come after implementation, then this mindset leads to wrong understanding and behaviour.</p>\n\n<p>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.</p>\n'}, {'answer_id': 54520, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 4, 'selected': False, 'text': '<p>There seem to be two types of BDD.</p>\n\n<p>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.</p>\n\n<p>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.</p>\n\n<p>There is also a BDD group which you might find useful:</p>\n\n<p><a href="http://groups.google.com/group/behaviordrivendevelopment/" rel="noreferrer">http://groups.google.com/group/behaviordrivendevelopment/</a></p>\n'}, {'answer_id': 905283, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 2, 'selected': False, 'text': '<p>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.</p>\n'}, {'answer_id': 26232155, 'author': 'Mihai', 'author_id': 1700417, 'author_profile': 'https://Stackoverflow.com/users/1700417', 'pm_score': 1, 'selected': False, 'text': '<p>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.</p>\n'}, {'answer_id': 30518187, 'author': 'phil v', 'author_id': 2324060, 'author_profile': 'https://Stackoverflow.com/users/2324060', 'pm_score': 2, 'selected': False, 'text': "<p>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.</p>\n<p>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.</p>\n<p>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.</p>\n<p>I would add that BDD tests serve as living requirements.</p>\n"}, {'answer_id': 34846654, 'author': 'Snehal Masne', 'author_id': 1792003, 'author_profile': 'https://Stackoverflow.com/users/1792003', 'pm_score': 0, 'selected': False, 'text': "<p>Here's the quick snapshot:</p>\n\n<blockquote>\n  <ul>\n  <li><p>TDD is just the process of testing code before writing it!</p></li>\n  <li><p>DDD is the process of being informed about the Domain before each    cycle of touching code!</p></li>\n  <li><p>BDD is an implementation of TDD which brings in some aspects of DDD!</p></li>\n  </ul>\n</blockquote>\n"}, {'answer_id': 42190310, 'author': 'thion', 'author_id': 5790233, 'author_profile': 'https://Stackoverflow.com/users/5790233', 'pm_score': 3, 'selected': False, 'text': '<p><strong>Test-Driven Development</strong> 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:</p>\n<blockquote>\n<p>The style here is to write a few lines of code, then a test that\nshould run, or even better, to write a test that won\'t run, then write\nthe code that will make it run.</p>\n</blockquote>\n<p>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 &quot;code a little, test a little, code a little, test a little.&quot; So we immediately write a test for it.</p>\n<p>So TDD is a low-level, technical methodology that programmers use to produce clean code that works.</p>\n<p><strong>Behaviour-Driven Development</strong> 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?</p>\n<p>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 <em>tests</em> can only be created by programmers and testers, <em>examples</em> can be collected and analysed by the entire delivery team—by designers, analysts, and so on.</p>\n<p>In a sentence, one of the best definitions of BDD I have <a href="https://www.infoq.com/presentations/bdd-introduction" rel="nofollow noreferrer">found</a> 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.</p>\n<p>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 <em>write code</em>—algorithms, design patterns, abstractions. Or, if you are a designer, you are taught to <em>design</em>—organize information and create beautiful interfaces. But when we get our entry-level jobs, our employers expect us to &quot;deliver value to the clients.&quot; 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.</p>\n<p><strong>Learn more</strong></p>\n<p>If you want to read more about BDD, I wrote a book on the subject. <strong><a href="https://www.manning.com/books/writing-great-specifications?a_aid=sbeug" rel="nofollow noreferrer">“Writing Great Specifications”</a></strong> 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.</p>\n<p>If you are interested in buying “Writing Great Specifications,” <strong>you can save 39%</strong> with the promo code <strong>39nicieja2</strong> :)</p>\n'}, {'answer_id': 57639038, 'author': 'saurabh singh', 'author_id': 10863282, 'author_profile': 'https://Stackoverflow.com/users/10863282', 'pm_score': 1, 'selected': False, 'text': '<p>In short there is major difference between TDD and BDD \nIn TDD we are majorly focused on Test data\nIn 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</p>\n'}]
['https://Stackoverflow.com/questions/2509', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/303/']