Behavior-driven development: Difference between revisions

Revision as of 23:02, 18 June 2020

Latest revision as of 00:21, 12 March 2025

(48 intermediate revisions by 39 users not shown)

Line 1:

{{short description|AgileSoftware softwaretest development processnaming}}

{{Software development process}}

'''Behavior-driven development''' ('''BDD''') involves naming [[software testing|software tests]] using [[Domain model|___domain language]] to describe the behavior of the [[source code|code]].

In [[software engineering]], '''behavior-driven development''' ('''BDD''') is an [[Agile software development]] process that encourages collaboration among developers, QA and non-technical or business participants in a software project.<ref name="IntroToBDD_DanNorth">{{cite web |url=http://dannorth.net/introducing-bdd/ |title=Introducing BDD |last1=North |first1=Dan |date=March 2006 |publisher=Dan North |accessdate=25 April 2019}}</ref><ref name="BDD_Def_BehaviourDriven">{{cite web |url=http://behaviour-driven.org/ |title=Behaviour-Driven Development |archiveurl=https://web.archive.org/web/20150901151029/http://behaviourdriven.org/ |archivedate=1 September 2015 |accessdate=12 August 2012}}</ref><ref name="IntroBDD">{{cite web |url=https://skillsmatter.com/skillscasts/934-introduction-to-behaviour-driven-development |title=Introduction to Behavior-Driven Development |last=Keogh |first=Liz |date=2009-09-07 |work=SkillsMatter |accessdate=1 May 2019}}</ref> It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.<ref name="BDD in action">{{cite book |title=BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle |author=John Ferguson Smart |publisher=Manning Publications |date=2014 |isbn= 9781617291654}}</ref> It emerged from [[test-driven development]] (TDD).<ref name="IntroToBDD_DanNorth"/><ref name="BDD_Def_BehaviourDriven"/><ref name="BDD_JW">{{cite journal |last1=Haring |first1=Ronald |date=February 2011 |title=Behavior Driven development: Beter dan Test Driven Development |editor-last = de Ruiter | editor-first = Robert |journal=Java Magazine |issue=1 |pages=14–17 |publisher=Veen Magazines |issn=1571-6236|language=nl}}</ref><ref>{{cite journal|last1=Solis|first1=Carlos|last2=Wang|first2=Xiaofeng|title=A Study of the Characteristics of Behaviour Driven Development|journal=Software Engineering and Advanced Applications (SEAA), 2011 37th EUROMICRO Conference on|pages=383–387|doi=10.1109/SEAA.2011.76|year=2011|isbn=978-1-4577-1027-8|hdl=10344/1256|hdl-access=free}}</ref>{{Vague|date=May 2015}}<ref name="BDD_CodeMagazine">{{cite web |url=http://www.code-magazine.com/article.aspx?quickid=0805061&page=1 |title=Behavior-Driven Development |last=Bellware |first=Scott |date=June 2008 |work=Code Magazine |accessdate=1 May 2019}}</ref> Behavior-driven development combines the general techniques and principles of TDD with ideas from [[___domain-driven design]] and [[object-oriented analysis and design]] to provide software development and management teams with shared tools and a shared process to collaborate on software development.<ref name="BDD_Def_BehaviourDriven"/><ref name="BDD_CodeMagazine" />

BDD involves use of a [[___domain-specific language]] (DSL) using natural-language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes.

Although BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process.<ref name="BDD_JW"/> Although these tools are often developed specifically for use in BDD projects, they can be seen as specialized forms of the tooling that supports test-driven development. The tools serve to add automation to the [[Domain-driven design#Building blocks|ubiquitous language]] that is a central theme of BDD.

BDDProponents isclaim largelyit facilitatedencourages throughcollaboration theamong usedevelopers, ofquality assurance experts, and customer representatives in a simplesoftware [[___domain-specificproject.<ref language]]name="BDD_Def_BehaviourDriven">{{cite (DSL)web using|url=http://behaviour-driven.org/ natural|title=Behaviour-languageDriven constructsDevelopment (e|archive-url=https://web.garchive.,org/web/20150901151029/http://behaviourdriven.org/ English|archive-likedate=1 sentences)September that2015 can|access-date=12 expressAugust the2012}}</ref><ref name="IntroBDD">{{cite web |last=Keogh |first=Liz |date=2009-09-07 |title=Introduction to Behavior-Driven Development |url=https://skillsmatter.com/skillscasts/934-introduction-to-behaviour-driven-development and|access-date=1 theMay expected2019 outcomes|work=SkillsMatterr |archive-date=2021-02-25 |archive-url=https://web.archive.org/web/20210225113241/https://skillsmatter.com/skillscasts/934-introduction-to-behaviour-driven-development |url-status=dead Test}}</ref> scriptsIt haveencourages longteams beento ause popularconversation applicationand ofconcrete DSLsexamples withto varyingformalize degreesa shared understanding of sophisticationhow the application should behave.<ref name="BDD in action">{{cite book |title=BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle |author=John Ferguson Smart |publisher=Manning Publications |date=2014 |isbn= 9781617291654}}</ref> BDD is considered an effective technical practice especially when the "''problem space" of the business problem to solve'' is complex.<ref name="When to adopt BDD">{{cite web |url= https://www.solutionsiq.com/resource/blog-post/behavior-driven-development-simplifying-the-complex-problem-space/|title=Behavior-Driven Development: Simplifying the Complex Problem Space |last=Tharayil |first=Ranjith|date=15 February 2016|work=SolutionsIQ |accessdateaccess-date=15 February 2018}}</ref>

BDD is considered a refinement of [[test-driven development]] (TDD).<ref name="BDD_Def_BehaviourDriven"/><ref name="BDD_JW">{{cite journal |last1=Haring |first1=Ronald |date=February 2011 |title=Behavior Driven development: Beter dan Test Driven Development |editor-last = de Ruiter | editor-first = Robert |journal=Java Magazine |issue=1 |pages=14–17 |publisher=Veen Magazines |issn=1571-6236|language=nl}}</ref><ref>{{cite book|last1=Solis|first1=Carlos|last2=Wang|first2=Xiaofeng|title=2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications |chapter=A Study of the Characteristics of Behaviour Driven Development |pages=383–387|doi=10.1109/SEAA.2011.76|year=2011|isbn=978-1-4577-1027-8|hdl=10344/1256|s2cid=3392536 |hdl-access=free}}</ref>{{Vague|date=May 2015}}<ref name="BDD_CodeMagazine">{{cite web |url=http://www.code-magazine.com/article.aspx?quickid=0805061&page=1 |title=Behavior-Driven Development |last=Bellware |first=Scott |date=June 2008 |work=Code Magazine |access-date=1 May 2019 |archive-url=https://web.archive.org/web/20120712114206/http://www.code-magazine.com/article.aspx?quickid=0805061&page=1 |archive-date=12 July 2012 |url-status=dead }}</ref><ref name="ATDD vs BDD">{{cite web|url=https://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/|author=Liz Keogh|title=ATDD vs. BDD, and a potted history of some related stuff|date=June 27, 2011|access-date=6 May 2019 }}</ref> BDD combines the techniques of TDD with ideas from [[___domain-driven design]] and [[object-oriented analysis and design]] to provide software development and management teams with shared tools and a shared process to collaborate on software development.<ref name="BDD_Def_BehaviourDriven"/><ref name="BDD_CodeMagazine" />

==History==

Behavior-driven development is an extension of [[test-driven development]]:<ref name="ATDD vs BDD">{{cite web|url=https://lizkeogh.com/2011/06/27/atdd-vs-bdd-and-a-potted-history-of-some-related-stuff/|author=Liz Keogh|title=ATDD vs. BDD, and a potted history of some related stuff|date=June 27, 2011|accessdate=6 May 2019 }}</ref> development that makes use of a simple, ___domain-specific scripting language. These DSLs convert structured natural language statements into executable tests. The result is a closer relationship to acceptance criteria for a given function and the tests used to validate that functionality. As such it is a natural extension of TDD testing in general.

At a high level, BDD is an idea about how software development should be managed by both business interests and technical insight. Its ''practice'' involves use of specialized tools.<ref name="BDD_JW"/> Some tools specifically for BDD can be used for TDD. The tools automate the [[Domain-driven design#Building blocks|ubiquitous language]].

== Overview ==

BDD is a process by which DSL structured natural-language statements are converted into executable tests. The result are tests that read like acceptance criteria for a given function.

As such, BDD is an extension of TDD.

BDD focuses on:

Line 18 ⟶ 25:

* How to understand why a test fails

At its heart, BDD is about rethinking the approach to [[automated testing]] (including [[unit testing]] and [[acceptance testing]]) in order to avoid issues that naturally arise. For example, BDD suggests that unit test names be whole sentences starting with a conditional verb ("should" in English for example) and should be written in order of business value. Acceptance tests should be written using the standard agile framework of a [[user story]]: "AsBeing a [role/actor/stakeholder] I want a [feature/capability] soyielding thata [benefit]". Acceptance criteria should be written in terms of scenarios and implemented asin classes: [[Given-When-Then|Given [initial context], when [event occurs], then [ensure some outcomes] ]].

Starting from this point, many people developed BDD frameworks over a period of years, finally framing it asin terms of a communication and collaboration framework for developers, [[quality assurance|QA]] and non-technical or business participants in a software project.<ref>[{{Cite web |url=http://forums.pragprog.com/forums/95/topics/3035 |title=The RSpec Book – Question about Chapter 11: Writing software that matters]</ref> During the "Agile specifications, BDD and Testing eXchange" in November |access-date=2009-08-09 in London, Dan North<ref>Dan North|archive-url=https: [//web.archive.org/web/20091107220359/http://skillsmatterforums.pragprog.com/podcastforums/java-jee95/howtopics/3035 |archive-todate=2009-sell11-bdd07 |url-to-the-businessstatus=dead How to sell BDD to the business]}}</ref> gave the following description of BDD:

<blockquote>

BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.</blockquote>

== Principles ==

During an interview with Dan North at GOTO Conference in 2013, Liz Keogh<ref name="Liz Keogh">{{cite web|url=https://lizkeogh.com/|title=Liz Keogh}}</ref> defines BDD as:

<blockquote>It's using examples to talk through how an application behaves... And having conversations about those examples.

<ref>GOTO 2013 • Interview with Liz Keogh & Dan North https://www.youtube.com/watch?v=g5WpUJk8He4</ref></blockquote>

BDD suggests that software tests should be named in terms of desired ''behavior''.<ref name="BDD_JW"/><ref name="BDD_CodeMagazine"/> Borrowing from [[agile software development]] the "desired behavior" in this case consists of the requirements set by the business &mdash; that is, the desired behavior that has [[business value]] for whatever entity commissioned the software unit under construction.<ref name="BDD_JW"/> Within BDD practice, this is referred to as BDD being an "outside-in" activity.

Dan North created a BDD framework, [[JBehave (software)|JBehave]], followed by a story-level BDD framework for Ruby called RBehave<ref name="rbehave">D.North, [http://dannorth.net/2007/06/introducing-rbehave Introducing RBehave]</ref> which was later integrated into the [[RSpec]] project.<ref name="rbehave-integ">S.Miller, [http://www.infoq.com/news/2007/10/RSpec-incorporates-RBehave InfoQ: RSpec incorporates RBehave]</ref> He also worked with David Chelimsky, Aslak Hellesøy and others to develop RSpec and also to write "The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends". The first story-based framework in RSpec was later replaced by [[Cucumber (software)|Cucumber]] mainly developed by [[Aslak Hellesøy]]. [[Capybara (software)|Capybara]], which is a part of the Cucumber testing framework is one such web-based test automation software.

TDD does not differentiate tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is an evolution of TDD which makes more specific choices.

==Principles of BDD==

Test-driven development is a software-development methodology which essentially states that for each unit of software, a software developer must:

===Behavioral specifications===

* define a test set for the unit ''first'';

* make the tests fail;

* then implement the unit;

* finally verify that the implementation of the unit makes the tests succeed.

Another BDD suggestion relates to ''how'' the desired behavior should be specified. BDD suggests using a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of [[object-oriented analysis and design]]. The [[Scenario (computing)|scenario]] aspect of this format may be regarded as an application of [[Hoare logic]] to behavioral specification of software using the ___domain-specific language.

This definition is rather non-specific in that it allows tests in terms of high-level software requirements, low-level technical details or anything in between. One way of looking at BDD therefore, is that it is a continued development of TDD which makes more specific choices than TDD.

BDD suggests that business analysts and software developers should collaborate in this area and should specify behavior in terms of user stories, which are each explicitly documented. Each user story should, to some extent, follow the structure:<ref name="BDD_JW"/>

Behavior-driven development specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.<ref name="BDD_JW"/><ref name="BDD_CodeMagazine"/><ref name="IntroToBDD_DanNorth"/> Borrowing from [[agile software development]] the "desired behavior" in this case consists of the requirements set by the business &mdash; that is, the desired behavior that has [[business value]] for whatever entity commissioned the software unit under construction.<ref name="BDD_JW"/><ref name="IntroToBDD_DanNorth"/> Within BDD practice, this is referred to as BDD being an "outside-in" activity.<ref name="WhatStory"/>

===Behavioral specifications===

Following this fundamental choice, a second choice made by BDD relates to ''how'' the desired behavior should be specified. In this area BDD chooses to use a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of [[object-oriented analysis and design]]. The [[Scenario (computing)|scenario]] aspect of this format may be regarded as an application of [[Hoare logic]] to behavioral specification of software units using the [[Domain-specific language|Domain Language]] of the situation.

BDD specifies that business analysts and developers should collaborate in this area and should specify behavior in terms of [[User story|user stories]], which are each explicitly written down in a dedicated document.<ref name="IntroToBDD_DanNorth"/><ref name="WhatStory">{{cite web |url=http://dannorth.net/whats-in-a-story/ |title=What's in a Story? |last1=North |first1=Dan |date=11 February 2007 |publisher=Dan North |accessdate=12 August 2012}}</ref> Each [[User story|User Story]] should, in some way, follow the following structure:<ref name="BDD_JW"/><ref name="WhatStory"/>

; Title: An explicit title.

Line 59 ⟶ 53:

:*'''Then''': the expected outcome, in one or more clauses.

{{anchor}}BDD does not require how this information is formatted, but it does suggest that a team should decide on a relatively simple, standardized format with the above elements.<ref name="BDD_JW"/> It also suggests that the scenarios should be phrased declaratively rather than imperatively — in the business language, with no reference to elements of the UI through which the interactions take place.<ref name="declarative">{{cite web |url=http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories.html |archive-url=https://web.archive.org/web/20100603235246/http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories.html |url-status=dead |archive-date=3 June 2010 |title=Imperative vs. Declarative Scenarios in user stories |last=Mabey |first=Ben |access-date=19 May 2008 }}</ref> This format is referred to in [[Cucumber (software)|Cucumber]] as the [[Cucumber_(software)#Gherkin_language|Gherkin language]].

{{anchor}}BDD does not have any formal requirements for exactly '''how''' these [[User story|user stories]] must be written down, but it does insist that each team using BDD come up with a simple, standardized format for writing down the [[User story|user stories]] which includes the elements listed above.<ref name="BDD_JW"/><ref name="WhatStory"/> However, in 2007 Dan North suggested a template for a textual format which has found wide following in different BDD software tools.<ref name="WhatStory"/> A very brief example of this format might look like this:

{{anchor|template_for_a_textual_format_exmple}}

===Specification as a ubiquitous language===

'''Title''': Returns and exchanges go to inventory.

'''As a''' store owner,

'''I want''' to add items back to inventory when they are returned or exchanged,

'''so that''' I can track inventory.

'''Scenario 1:''' Items returned for refund should be added to inventory.

'''Given''' that a customer previously bought a black sweater from me

'''and''' I have three black sweaters in inventory,

'''when''' they return the black sweater for a refund,

'''then''' I should have four black sweaters in inventory.

'''Scenario 2:''' Exchanged items should be returned to inventory.

'''Given''' that a customer previously bought a blue garment from me

'''and''' I have two blue garments in inventory

'''and''' three black garments in inventory,

'''when''' they exchange the blue garment for a black garment,

'''then''' I should have three blue garments in inventory

'''and''' two black garments in inventory.

BDD borrows the concept of the ''ubiquitous language'' from [[___domain driven design]].<ref name="BDD_JW"/><ref name="BDD_CodeMagazine"/> A ubiquitous language is a (semi-)formal language that is shared by all members of a software development team &mdash; both software developers and non-technical personnel.<ref name="DDD_Evans">{{cite book |title=Domain-Driven Design: Tackling Complexity in the Heart of Software |last=Evans |first=Eric |year=2003 |publisher=Addison-Wesley |isbn=978-0-321-12521-7 |access-date=August 12, 2012 |url=http://www.domaindrivendesign.org/books/evans_2003}}</ref> The language in question is both used and developed by all team members as a common means of discussing the ___domain of the software in question.<ref name="DDD_Evans"/> In this way BDD becomes a vehicle for communication between all the different roles in a software project.<ref name="BDD_JW"/>

The [[Scenario (computing)|scenarios]] are ideally phrased declaratively rather than imperatively — in the business language, with no reference to elements of the UI through which the interactions take place.<ref name="declarative">{{cite web |url=http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories.html |archive-url=https://web.archive.org/web/20100603235246/http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories.html |url-status=dead |archive-date=3 June 2010 |title=Imperative vs. Declarative Scenarios in user stories |last=Mabey |first=Ben |accessdate=19 May 2008 }}</ref>

This format is referred to as the Gherkin language, which has a syntax similar to the above example. The term ''Gherkin'', however, is specific to the [[Cucumber_(software)|Cucumber]], JBehave, Lettuce<ref>{{Cite web|url=http://lettuce.it/|title=nutshell — Lettuce 0.2.23 (kryptonite release) documentation|website=lettuce.it|access-date=2020-02-06}}</ref>, behave and [[Behat (computer science)|Behat]] software tools.<ref name="Gherkin">{{cite web |url=https://cucumber.io/docs/gherkin/reference/ |title=Gherkin |accessdate=7 June 2020}}</ref><ref name="JBehave">{{cite web |url=http://jbehave.org/ |title=What is JBehave?|website=JBehave.org |accessdate=20 October 2015}}</ref><ref name="behave">{{cite web |url=http://pythonhosted.org/behave/ |title=behave is behaviour-driven development, Python style |accessdate=30 January 2018 |archive-url=https://web.archive.org/web/20180122123313/http://pythonhosted.org/behave/ |archive-date=22 January 2018 |url-status=dead }}</ref><ref name="Behat">{{cite web |url=http://behat.readthedocs.org/en/v3.0/guides/1.gherkin.html |title=Writing Features - Behat 3.0.12 documentation |website=behat documentation |accessdate=20 October 2015 |url-status=dead |archiveurl=https://web.archive.org/web/20150919215413/http://behat.readthedocs.org/en/v3.0/guides/1.gherkin.html |archivedate=19 September 2015 }}</ref>

===Specification as a ubiquitous language===

Behavior-driven development borrows the concept of the ''ubiquitous language'' from [[___domain driven design]].<ref name="BDD_JW"/><ref name="BDD_CodeMagazine"/> A ubiquitous language is a (semi-)formal language that is shared by all members of a software development team &mdash; both software developers and non-technical personnel.<ref name="DDD_Evans">{{cite book |title=Domain-Driven Design: Tackling Complexity in the Heart of Software |last=Evans |first=Eric |authorlink=Eric Evans (technologist) |year=2003 |publisher=Addison-Wesley |isbn=978-0-321-12521-7 |accessdate=August 12, 2012 |url=http://www.domaindrivendesign.org/books/evans_2003}}</ref> The language in question is both used and developed by all team members as a common means of discussing the ___domain of the software in question.<ref name="DDD_Evans"/> In this way BDD becomes a vehicle for communication between all the different roles in a software project.<ref name="BDD_JW"/><ref name="BDD_comm_North">{{cite web |url=http://dannorth.net/2012/05/31/bdd-is-like-tdd-if/ |title=BDD is like TDD if… |last=North |first=Dan |date=31 May 2012 |work=faster organisations, faster software |publisher=Dan North & Associates |accessdate=12 August 2012}}</ref>

A common risk with software development includes communication breakdowns between Developers and Business Stakeholders.<ref name="BDD_comms">{{cite web |url=http://www.geneca.com/75-business-executives-anticipate-software-projects-fail/ |title=Why Software Projects Fail |author=Geneca |date=16 Mar 2011 |accessdateaccess-date=16 March 2011}}</ref> BDD uses the specification of desired behavior as a ubiquitous language for the project Team members. This is the reason that BDD insists on a semi-formal language for behavioral specification: some formality is a requirement for being a ubiquitous language.<ref name="BDD_JW"/> In addition, having such a ubiquitous language creates a ___domain model of specifications, so that specifications may be reasoned about formally.<ref name="BDD_CodeProj">{{cite web |url=http://www.codeproject.com/Articles/148043/Say-Hello-To-Behavior-Driven-Development-BDD-Part |title=Say Hello To Behavior Driven Development |author=Mahmudul Haque Azad |date=6 Feb 2011 |accessdateaccess-date=12 August 2012}}</ref> This model is also the basis for the different BDD-supporting software tools that are available.

The example given above establishes a user story for a software system under development. This user story identifies a stakeholder, a business effect and a business value. It also describes several scenarios, each with a precondition, trigger and expected outcome. Each of these parts is exactly identified by the more formal part of the language (the term '''Given''' might be considered a [[keyword (computer programming)|keyword]], for example) and may therefore be processed in some way by a tool that understands the formal parts of the ubiquitous language.

Line 97 ⟶ 67:

doi= 10.1109/MS.2016.117 |

title = Modeling Test Cases in BPMN for Behavior-Driven Development |

journal = IEEE Software | volume = 33 | issue = 5 | pages = 15–21 | year = 2016 |author1=Lübke, Daniel |author2=van Lessen, Tammo }}</ref>|

s2cid = 14539297 }}</ref>

== Specialized tooling support==

Much like test-driven design practice, behavior-driven development assumes the use of specialized support tooling in a project. BDD can be seen as a more specific version of TDD, as it requires to supply not only test code but a separate document in addition to describe the behavior in a more human-readable language. This requires a two-step process for executing the tests, reading and parsing the descriptions, and reading the test code and finding the corresponding test implementation to execute. This process makes BDD slightly more laborious to work with as a developer, but due to its human-readable nature the value of those documents extends to an even less technical audience, and can hence serve as a communication means for describing requirements ("features").

Much like TDD, BDD may involve using specialized tooling.

===Tooling principles===

In principle a BDD support tool is a testing framework for software, much like the tools that support TDD. However, where TDD tools tend to be quite free-format in what is allowed for specifying tests, BDD tools are linked to the definition of the ubiquitous language discussed earlier.

BDD requires not only test code as does TDD, but also a document that describes behavior in a more human-readable language. This requires a two-step process for executing the tests, reading and parsing the descriptions, and reading the test code and finding the corresponding test implementation to execute. This process makes BDD more laborious for developers. Proponents suggest that due to its human-readable nature the value of those documents extends to a relatively non-technical audience, and can hence serve as a communication means for describing requirements ("features").

As discussed, the ubiquitous language allows business analysts to write down behavioral requirements in a way that will also be understood by developers. The principle of BDD support tooling is to make these same requirements documents directly executable as a collection of tests. If this cannot be achieved because of reasons related to the technical tool that enables the execution of the specifications, then either the style of writing the behavioral requirements must be altered or the tool must be changed.<ref name="BDD_Enterprise">{{cite web |url=http://www.methodsandtools.com/archive/entreprisebdd.php |title=Fundamentals of Enterprise-Scale Behaviour-Driven Development (BDD) |author=Adam Craven |date=September 21, 2015 | accessdate=14 January 2016}}</ref> The exact implementation of behavioral requirements varies per tool, but agile practice has come up with the following general process:

=== Tooling principles ===

In principle, a BDD support tool is a testing framework for software, much like the tools that support TDD. However, where TDD tools tend to be quite free-format in what is allowed for specifying tests, BDD tools are linked to the definition of the ubiquitous language.

The ubiquitous language allows business analysts to document behavioral requirements in a way that will also be understood by developers. The principle of BDD support tooling is to make these same requirements documents directly executable as a collection of tests. If this cannot be achieved because of reasons related to the technical tool that enables the execution of the specifications, then either the style of writing the behavioral requirements must be altered or the tool must be changed.<ref name="BDD_Enterprise">{{cite web |url=http://www.methodsandtools.com/archive/entreprisebdd.php |title=Fundamentals of Enterprise-Scale Behaviour-Driven Development (BDD) |author=Adam Craven |date=September 21, 2015 | access-date=14 January 2016}}</ref> The exact implementation of behavioral requirements varies per tool, but agile practice has come up with the following general process:

* The tooling reads a specification document.

Line 111 ⟶ 86:

* Each individual clause in a scenario is transformed into some sort of parameter for a test for the user story. This part requires project-specific work by the software developers.

* The framework then executes the test for each scenario, with the parameters from that scenario.

Dan North has developed a number of frameworks that support BDD (including JBehave and [[RBehave]]), whose operation is based on the template that he suggested for recording user stories.<ref name="BDD_JW"/> These tools use a textual description for use cases and several other tools (such as CBehave) have followed suit. However, this format is not required and so there are other tools that use other formats as well. For example, [[Fitnesse]] (which is built around [[decision table]]s), has also been used to roll out BDD.<ref name="FitNesse_BDD">{{cite web |url=http://ketiljensen.wordpress.com/2009/12/13/bdd-with-scenario-tables-in-fitnesse-slim/ |title=BDD with Scenario tables in Fitnesse Slim |author=Ketil Jensen |date=December 13, 2009 |work=Walk the walk |publisher=Wordpress |accessdate=12 August 2012}}</ref>

===Tooling examples===

There are several different examples of BDD software tools in use in projects today, for different platforms and programming languages.

Possibly the most well-known is JBehave, which was developed by Dan North, Elizabeth Keogh and several others.<ref name = "JBehave Team">{{cite web |url=https://jbehave.org/team-list.html |title=jbehave.org/team-list|date=2017-05-28 |publisher=JBehave |accessdate=1 May 2019}}</ref> The following is an example taken from that project:<ref name="JBehave" />

Consider an implementation of the [[Conway's Game of Life|Game of Life]]. A ___domain expert (or business analyst) might want to specify what should happen when someone is setting up a starting configuration of the game grid. To do this, he might want to give an example of a number of steps taken by a person who is toggling cells. Skipping over the narrative part, he might do this by writing up the following scenario into a plain text document (which is the type of input document that JBehave reads):

'''Given''' a 5 by 5 game

'''When''' I toggle the cell at (3, 2)

'''Then''' the grid should look like

.....

.....

.....

..X..

.....

'''When''' I toggle the cell at (3, 1)

'''Then''' the grid should look like

.....

.....

.....

..X..

..X..

'''When''' I toggle the cell at (3, 2)

'''Then''' the grid should look like

.....

.....

.....

.....

..X..

The bold print is not part of the input; it is included here to show which words are recognized as formal language. JBehave recognizes the terms ''Given'' (as a precondition which defines the start of a scenario), ''When'' (as an event trigger) and ''Then'' (as a postcondition which must be verified as the outcome of the action that follows the trigger). Based on this, JBehave is capable of reading the text file containing the scenario and [[parsing]] it into clauses (a set-up clause and then three event triggers with verifiable conditions). JBehave then takes these clauses and passes them on to code that is capable of setting a test, responding to the event triggers and verifying the outcome. This code must be written by the developers in the project team (in [[Java (programming language)|Java]], because that is the platform JBehave is based on). In this case, the code might look like this:

<syntaxhighlight lang="java">

private Game game;

private StringRenderer renderer;

@Given("a $width by $height game")

public void theGameIsRunning(int width, int height) {

game = new Game(width, height);

renderer = new StringRenderer();

game.setObserver(renderer);

}

@When("I toggle the cell at ($column, $row)")

public void iToggleTheCellAt(int column, int row) {

game.toggleCellAt(column, row);

}

@Then("the grid should look like $grid")

public void theGridShouldLookLike(String grid) {

assertThat(renderer.asString(), equalTo(grid));

}

</syntaxhighlight>

The code has a method for every type of clause in a scenario. JBehave will identify which method goes with which clause through the use of [[annotation]]s and will call each method in order while running through the scenario. The text in each clause in the scenario is expected to match the template text given in the code for that clause (for example, a '''Given''' in a scenario is expected to be followed by a clause of the form "a X by Y game"). JBehave supports the matching of clauses to templates and has built-in support for picking terms out of the template and passing them to methods in the test code as parameters. The test code provides an implementation for each clause type in a scenario which interacts with the code that is being tested and performs a test based on the scenario. In this case:

* The <code>theGameIsRunning</code> method reacts to a '''Given''' clause by setting up the initial game grid.

* The <code>iToggleTheCellAt</code> method reacts to a '''When''' clause by firing off the toggle event described in the clause.

* The <code>theGridShouldLookLike</code> method reacts to a '''Then''' clause by comparing the state of the game grid to the expected state from the scenario.

The primary function of this code is to be a bridge between a text file with a story and the code being tested. Note that the test code has access to the code being tested (in this case an instance of <code>Game</code>) and is very simple in nature. The test code has to be simple, otherwise a developer would end up having to write tests for his tests.

Finally, in order to run the tests, JBehave requires some plumbing code that identifies the text files which contain scenarios and which inject dependencies (like instances of <code>Game</code>) into the test code. This plumbing code is not illustrated here, since it is a technical requirement of JBehave and does not relate directly to the principle of BDD-style testing.

==Story versus specification==

A separate subcategory of behavior-driven development is formed by tools that use specifications as an input language rather than [[User story|user stories]]. An example of this style is the [[RSpec]] tool that was also originally developed by Dan North. Specification tools don't use [[User story|user stories]] as an input format for [[Scenario testing|test scenarios]] but rather use functional specifications for units that are being tested. These specifications often have a more technical nature than user stories and are usually less convenient for communication with business personnel than are user stories.<ref name="BDD_JW"/><ref name="BDD_SPEC_OSHEROVE">{{cite web |url=http://osherove.com/blog/2008/10/4/bdd-behavior-vs-spec-frameworks.html |title=BDD: Behavior vs. Spec Frameworks |author=Roy Osherove |date=October 4, 2008 |accessdateaccess-date=12 August 2012}}</ref> An example of a specification for a [[stack (abstract data type)|stack]] might look like this:

'''Specification:''' Stack

Line 194 ⟶ 103:

'''And''' the new size of the stack is N-1

Such a specification may exactly specify the behavior of the component being tested, but is less meaningful to a business user. As a result, specification-based testing is seen in BDD practice as a complement to story-based testing and operates at a lower level. Specification testing is often seen as a replacement for free-format [[unit testing]].<ref name="BDD_SPEC_OSHEROVE"/>

Specification testing tools like RSpec and JDave are somewhat different in nature from tools like JBehave. Since they are seen as alternatives to basic unit testing tools like [[JUnit]], these tools tend to favor forgoing the separation of story and testing code and prefer embedding the specification directly in the test code instead. For example, an RSpec test for a [[hashtable]] might look like this:<ref name="RSpec_Hash">{{cite web |url=http://blog.teamtreehouse.com/an-introduction-to-rspec |title=An Introduction To RSpec |author=Jason Seifer |date=7 December 2011 |accessdate=27 October 2012}}</ref>

<syntaxhighlight lang="ruby">

describe Hash do

let(:hash) { Hash[:hello, 'world'] }

it { expect(Hash.new).to eq({}) }

it "hashes the correct information in a key" do

expect(hash[:hello]).to eq('world')

end

it 'includes key' do

hash.keys.include?(:hello).should be true

end

end

</syntaxhighlight>

This example shows a specification in readable language embedded in executable code. In this case a choice of the tool is to formalize the specification language into the language of the test code by adding methods named <code>it</code> and <code>should</code>. Also there is the concept of a specification precondition &ndash; the <code>before</code> section establishes the preconditions that the specification is based on.

== The three amigos ==

The result of test will be:

Hash

should eq {}

includes key

hashes the correct information in a key

The "three amigos", also referred to as a "Specification Workshop", is a meeting where the product owner discusses the requirement in the form of specification by example with different stakeholders like the QA and development team. The key goal for this discussion is to trigger conversation and identify any missing specifications. The discussion also gives a platform for QA, development team and product owner to converge and hear out each other's perspective to enrich the requirement and also make sure if they are building the right product.<ref>{{Cite web|url=https://www.agilealliance.org/glossary/three-amigos/|title=What are the Three Amigos in Agile?|date=2016-06-16|website=Agile Alliance|language=en-US|access-date=2019-06-10}}</ref>

==The Three Amigos==

The Three Amigos, also referred to as a "Specification Workshop", is a meeting where the Product Owner discusses the requirement in the form of Specification by Example with different stakeholders like the QA and development team. The key goal for this discussion is to trigger conversation and identify any missing specifications. The discussion also gives a platform for QA, development team and Product owner to converge and hear out each other's perspective to enrich the requirement and also make sure if they are building the right product.<ref>{{Cite web|url=https://www.agilealliance.org/glossary/three-amigos/|title=What are the Three Amigos in Agile?|date=2016-06-16|website=Agile Alliance|language=en-US|access-date=2019-06-10}}</ref>

The three Amigosamigos are :

* Business - Role of the Businessbusiness user is to define the problem only (and not venture into suggesting anya solution)

* Development - Role of the Developersdevelopers involve to suggestsuggesting ways to fix the problem

* Testing - Role of testers is to question the solution, bring up as many as different possibilities for brain storming through Whatwhat-Ifif scenarios and help make the solution more precise to fix the problem.

==See also==

* [[Specification by example|Specification by Example]]

* [[Behat (computer science)|Behat]] (PHP framework)

* [[Cynefin framework]]

* [[Concordion]] (Java framework)

* [[RSpec]]

* [[Cucumber (software)|Cucumber]] (originally a Ruby framework, also available for Java, JavaScript and other languages)

* [[Gauge (software)|Gauge]]

* [[Jasmine (JavaScript testing framework)]]

* [[Squish (Froglogic)|Squish GUI Tester]] (BDD GUI Testing Tool for JavaScript, Python, Perl, Ruby and Tcl)

* [[Use case]]

* [[Fitnesse]] has been used to roll out BDD<ref name="FitNesse_BDD">{{cite web |url=http://ketiljensen.wordpress.com/2009/12/13/bdd-with-scenario-tables-in-fitnesse-slim/ |title=BDD with Scenario tables in Fitnesse Slim |author=Ketil Jensen |date=December 13, 2009 |work=Walk the walk |publisher=Wordpress |access-date=12 August 2012}}</ref>

==References==