Behavior-driven development: Difference between revisions

Revision as of 04:25, 29 February 2024

Revision as of 15:20, 16 April 2024

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 a software development process that encourages collaboration among developers, quality assurance experts, and customer representatives 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 |access-date=25 April 2019}}</ref><ref name="BDD_Def_BehaviourDriven">{{cite web |url=http://behaviour-driven.org/ |title=Behaviour-Driven Development |archive-url=https://web.archive.org/web/20150901151029/http://behaviourdriven.org/ |archive-date=1 September 2015 |access-date=12 August 2012}}</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 |access-date=1 May 2019 |work=SkillsMatter |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 }}</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) and can work alongside an [[agile software development]] process.<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 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> 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 [[___domainproject.<ref name="IntroToBDD_DanNorth">{{cite web |url=http://dannorth.net/introducing-specificbdd/ language]]|title=Introducing (DSL)BDD using|last1=North natural|first1=Dan |date=March 2006 |publisher=Dan North |access-languagedate=25 constructsApril (e2019}}</ref><ref name="BDD_Def_BehaviourDriven">{{cite web |url=http://behaviour-driven.gorg/ |title=Behaviour-Driven Development |archive-url=https://web.,archive.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=SkillsMatter |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 formalize a varyingshared degreesunderstanding 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 |access-date=15 February 2018}}</ref>

In [[software engineering]], '''behavior-driven development''' ('''BDD''') is a software development process that encourages collaboration among developers, quality assurance experts, and customer representatives inconsidered 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 |access-date=25 April 2019}}</ref><ref name="BDD_Def_BehaviourDriven">{{cite web |url=http://behaviour-driven.org/ |title=Behaviour-Driven Development |archive-url=https://web.archive.org/web/20150901151029/http://behaviourdriven.org/ |archive-date=1 September 2015 |access-date=12 August 2012}}</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 |access-date=1 May 2019 |work=SkillsMatter |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 }}</ref> It encourages teams to use conversation and concrete examples to formalize a shared understandingrefinement 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) and can work alongside an [[agile software development]] process.<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 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> Behavior<ref name="ATDD vs BDD">{{cite web|url=https://lizkeogh.com/2011/06/27/atdd-vs-bdd-drivenand-a-potted-history-of-some-related-stuff/|author=Liz developmentKeogh|title=ATDD combinesvs. theBDD, generaland techniquesa andpotted principleshistory 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, 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|access-date=6 May 2019 }}</ref> is a development process that makes use of a simple DSL. 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.

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

== Overview ==

BDD is a process by which DSL structured natural language statements are converted to 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]]: "Being a [role/actor/stakeholder] I want a [feature/capability] yielding a [benefit]". Acceptance criteria should be written in terms of scenarios and implemented in 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 in 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 |access-date=2009-08-09 |archive-url=https://web.archive.org/web/20091107220359/http://forums.pragprog.com/forums/95/topics/3035 |archive-date=2009-11-07 |url-status=dead }}</ref> During the "Agile specifications, BDD and Testing eXchange" in November 2009 in London, Dan North<ref>{{Cite web|author=Dan North|title=How to sell BDD to the business|url=https://skillsmatter.com/skillscasts/923-how-to-sell-bdd-to-the-business|access-date=2023-02-07|website=skillsmatter.com|language=en|archive-url=https://web.archive.org/web/20101125022509/http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business |archive-date=2010-11-25}}</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>

== History ==

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> defined BDD as:

Line 30 ⟶ 39:

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] {{Webarchive|url=https://web.archive.org/web/20070620230359/http://dannorth.net/2007/06/introducing-rbehave |date=2007-06-20 }}</ref> which was later integrated into the [[RSpec]] project.<ref name="rbehave-integ">{{Cite web|author=Sean Miller|title=RSpec Adds Eagerly-Awaited RBehave Functionality for Integration Testing|url=https://www.infoq.com/news/2007/10/RSpec-incorporates-RBehave/|date=October 31, 2007|access-date=2023-02-07|website=InfoQ|language=en}}</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.

==Principles ofPrinciples BDD==

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

* 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.

Behavior-drivenBDD development specifiessuggests that software tests of any unit of software should be specifiednamed 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"/>

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.

ThisTDD definitiondoes is rather non-specific in that itnot allowsdifferentiate 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 aan continued developmentevolution of TDD which makes more specific choices than TDD.

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 of the situation.

FollowingAnother thisBDD fundamental choice, a second choice made by BDDsuggestion relates to ''how'' the desired behavior should be specified. In this area BDD choosessuggests to useusing 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 of the situation.

BDD specifies that business analysts and developers should collaborate in this area and should specify behavior in terms of 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 |access-date=12 August 2012}}</ref> Each user story should, in some way, follow the following structure:<ref name="BDD_JW"/><ref name="WhatStory"/>

BDD specifiessuggests that business analysts and software developers should collaborate in this area and should specify behavior in terms of user stories, which are each explicitly written down in a dedicated documentdocumented.<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 |access-date=12 August 2012}}</ref> Each user story should, into some wayextent, follow the following structure:<ref name="BDD_JW"/><ref name="WhatStory"/>

; Title: An explicit title.

Line 58 ⟶ 63:

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

{{anchor}}BDD does not haverequire any formal requirements for exactly '''how''' these user stories mustthis beinformation writtenis downformatted, but it does insistsuggest that eacha team usingshould BDDdecide comeon upa with arelatively simple, standardized format for writing downwith the user stories which includes theabove elements listed above.<ref name="BDD_JW"/><ref name="WhatStory"/> However, inIn 2007, Dan North suggested a template for a textual format which hasis found wide followingused in differentmultiple BDD software tools.<ref name="WhatStory"/> A very briefFor example of this format might look like this:

{{anchor|template_for_a_textual_format_exmple}}

Line 81 ⟶ 86:

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

TheBDD suggested that the scenarios areshould ideallybe 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 as the [[Cucumber_(software)#Gherkin_language|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 |access-date=7 June 2020}}</ref><ref name="JBehave">{{cite web |url=http://jbehave.org/ |title=What is JBehave?|website=JBehave.org |access-date=20 October 2015}}</ref><ref name="behave">{{cite web |url=http://pythonhosted.org/behave/ |title=behave is behaviour-driven development, Python style |access-date=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 |access-date=20 October 2015 |url-status=dead |archive-url=https://web.archive.org/web/20150919215413/http://behat.readthedocs.org/en/v3.0/guides/1.gherkin.html |archive-date=19 September 2015 }}</ref>

===Specification as a ubiquitous language===

Behavior-driven developmentBDD 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 |author-link=Eric Evans (technologist) |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"/><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 |access-date=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 |access-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 |access-date=12 August 2012}}</ref> This model is also the basis for the different BDD-supporting software tools that are available.

Line 99 ⟶ 105:

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.

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 butas adoes separateTDD, documentbut inalso additiona todocument describethat thedescribes 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 tofor workdevelopers. withProponents assuggest a developer, butthat due to its human-readable nature the value of those documents extends to ana even lessrelatively 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 | 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:

=== 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.

As discussed, theThe ubiquitous language allows business analysts to write downdocument 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 222 ⟶ 232:

hashes the correct information in a key

== The Threethree amigos Amigos==

The Threethree Amigosamigos, also referred to as a "Specification Workshop", is a meeting where the Productproduct Ownerowner discusses the requirement in the form of Specificationspecification by Exampleexample 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 Productproduct 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==