{"id":5003122,"date":"2015-12-16T21:21:10","date_gmt":"2015-12-17T05:21:10","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=5003122"},"modified":"2023-10-18T12:42:28","modified_gmt":"2023-10-18T19:42:28","slug":"bdd","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/bdd\/","title":{"rendered":"Behavior Driven Development (BDD)"},"content":{"rendered":"<h3 style=\"text-align: center;\"><\/h3>\n<div>\n<div>\n<p>Behaviour Driven Development (BDD) is a synthesis and refinement of practices stemming from\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/tdd\/\">Test Driven Development<\/a>\u00a0(TDD) and\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/atdd\/\">Acceptance Test Driven Development<\/a>\u00a0(ATDD). BDD augments TDD and ATDD with the following tactics:<\/p>\n<ul>\n<li>Apply the\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/5_Whys\" target=\"_blank\" rel=\"noopener noreferrer\">\u201cFive Why\u2019s\u201d<\/a>\u00a0principle to each proposed\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/user-stories\/\">user story<\/a>, so that its purpose is clearly related to business outcomes<\/li>\n<li>thinking \u201cfrom the outside in\u201d, in other words, implement only those behaviors which contribute most directly to these business outcomes, so as to minimize waste<\/li>\n<li>describe behaviors in a single notation that is directly accessible to domain experts, testers, and developers, so as to improve communication<\/li>\n<li>apply these techniques all the way down to the lowest levels of abstraction of the software, paying particular attention to the distribution of behavior, so that evolution remains cheap<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Also Known As<\/h2>\n<div>\n<div>\n<p>BDD is also referred to as Specification by Example.<\/p>\n<\/div>\n<\/div>\n<h2>Expected Benefits<\/h2>\n<div>\n<div>\n<p>Teams already using TDD or ATDD may want to consider BDD for several reasons:<\/p>\n<ul>\n<li>BDD offers more precise guidance on organizing the conversation between developers, testers, and domain experts<\/li>\n<li>notations originating in the BDD approach, in particular the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/gwt\/\">given-when-then<\/a>\u00a0canvas, are closer to everyday language and have a shallower learning curve compared to those of tools such as Fit\/FitNesse<\/li>\n<li>tools targeting a BDD approach generally afford the automatic generation of technical and end-user documentation from BDD \u201cspecifications\u201d<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Common Pitfalls<\/h2>\n<div>\n<div>\n<p>Although Dan North, who first formulated the BDD approach, claims that it was designed to address recurring issues in the teaching of TDD, it is clear that BDD requires familiarity with a greater range of concepts than TDD does, and it seems difficult to recommend a novice programmer should first learn BDD without prior exposure to TDD concepts<\/p>\n<p>The use of BDD requires no particular tools or programming languages, and is primarily a conceptual approach; to make it a purely technical practice or one that hinges on specific tooling would be to miss the point altogether<\/p>\n<\/div>\n<\/div>\n<h2>Origins<\/h2>\n<div>\n<div>\n<ul>\n<li>2003:\u00a0<a href=\"http:\/\/agiledox.sourceforge.net\/\" target=\"_blank\" rel=\"noopener noreferrer\">agiledox<\/a>, the ancestor of BDD, is a tool generating technical documentation automatically from JUnit tests, written by Chris Stevenson<\/li>\n<li>2004: Chris Matts and Dan North proposed the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/gwt\/\">given-when-then<\/a>\u00a0canvas to expand the scope of BDD to business analysis and documents<\/li>\n<li>2004: in order to test his hypotheses about de-emphasizing \u201ctest\u201d terminology in favor of \u201cbehavior\u201d, Dan North releases\u00a0<a href=\"http:\/\/jbehave.org\/\" target=\"_blank\" rel=\"noopener noreferrer\">JBehave<\/a><\/li>\n<li>2006:\u00a0Dan North documents the approach in \u00a0<a href=\"http:\/\/blog.dannorth.net\/introducing-bdd\/\">\u201cIntroducing BDD\u201d<\/a><\/li>\n<li>2006-2009: several new tools are released confirming the community\u2019s investment in BDD, such as RSpec or more recently, Cucumber and GivWenZen<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Signs of Use<\/h2>\n<div>\n<div>\n<ul>\n<li>A team using BDD should be able to provide a significant portion of \u201cfunctional documentation\u201d in the form of User Stories augmented with executable scenarios or examples.<\/li>\n<li>Instead of referring to \u201ctests\u201d, a BDD practitioner will prefer the terms \u201cscenario\u201d and \u201cspecification\u201d. As currently practiced, BDD aims to gather in a single place the specification of an outcome valuable to a user, generally using the\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/role-feature\/\">role-feature<\/a>\u00a0matrix of (<a href=\"https:\/\/agilealliance.org\/glossary\/user-stories\/\">User Stories<\/a>), as well as examples or scenarios expressed in the form\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/gwt\/\">given-when-then<\/a>; these two notations are often considered the most readable.<\/li>\n<li>In emphasizing the term \u201cspecification\u201d, the intent of BDD is to provide a single answer to what many Agile teams view as separate activities: the creation of unit tests and \u201ctechnical\u201d code, on one hand, the creation of functional tests and \u201cfeatures\u201d on the other hand. This should lead to increased collaboration between developers, test specialists, and domain experts.<\/li>\n<li>Rather than refer to \u201cthe unit tests of a class\u201d, a practitioner or a team using BDD prefers to speak of \u201cthe specifications of the behavior of the class\u201d. This reflects a greater focus on the documentary role of such specifications: their names are expected to be more expressive, and, when completed with their description in\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/gwt\/\">given-when-then<\/a>\u00a0format, to serve as technical documentation.<\/li>\n<li>Rather than refer to \u201cfunctional tests\u201d, the preferred term will be \u201cspecifications of the product\u2019s behavior\u201d. The technical aspects of BDD are placed on an equal footing with techniques encouraging more effective conversation with customers, users, and domain experts.<\/li>\n<li>In addition to\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/refactoring\/\">refactoring<\/a> techniques already present in TDD, the design philosophy in BDD pays particular attention to the appropriate distribution of responsibilities among classes, which leads its practitioners to emphasize\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/mocks\/\">\u201cmocking\u201d<\/a>.<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<h2>Further Reading<\/h2>\n<div>\n<div>\n<p><a href=\"https:\/\/dannorth.net\/introducing-bdd\/\" target=\"_blank\" rel=\"noopener noreferrer\">\u201cIntroducing BDD\u201d<\/a>, by Dan North (2006)<\/p>\n<p><a href=\"http:\/\/lizkeogh.com\/2009\/11\/06\/translating-tdd-to-bdd\/\" target=\"_blank\" rel=\"noopener noreferrer\">\u201cTranslating TDD to BDD\u201d<\/a>, by Liz Keogh (2009)<\/p>\n<p><a href=\"http:\/\/www.citeulike.org\/user\/Scis0000002\/article\/7536581\" target=\"_blank\" rel=\"noopener noreferrer\">A tool stack for implementing Behaviour-Driven Development in Python Language<\/a>\u00a0by\u00a0Tavares, Rezende, dos Santos, Manhaes, de Carvalho (2010)<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>BDD is a practice where members of the team discuss the expected behavior of a system in order to build a shared understanding of expected functionality.<\/p>\n","protected":false},"author":6000331,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[904],"tags":[787,791],"class_list":["post-5003122","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-business","tag-atdd","tag-bdd"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003122","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/6000331"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=5003122"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003122\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=5003122"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=5003122"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=5003122"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}