|
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.
Proponents claim it 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=SkillsMatterSkillsMatterr |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> BDD is considered an effective practice especially when the ''problem space'' 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>
BDD is considered a refinement of [[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 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" />
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 tointo 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:
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:
<blockquote>It's using examples to talk through how an application behaves... And having conversations about those examples.
<ref>{{Citation|title=Interview with Liz Keogh & Dan North • GOTO 2013|url=https://www.youtube.com/watch?v=g5WpUJk8He4|language=en|access-date=2023-02-07}}</ref></blockquote>
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 ==
BDD suggests that software tests should be named in terms of desired ''behavior''.<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 — 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"/>
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.
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.
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.<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, to some extent, follow the structure:<ref name="BDD_JW"/><ref name="WhatStory"/>
; Title: An explicit title.
:*'''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"/><ref name="WhatStory"/>It Inalso 2007,suggests Danthat Norththe suggestedscenarios ashould templatebe forphrased adeclaratively textualrather formatthan which isimperatively used— in multiplethe BDDbusiness toolslanguage, with no reference to elements of the UI through which the interactions take place.<ref name="WhatStorydeclarative"/>{{cite Forweb example|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|template_for_a_textual_format_exmple}}
'''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 sell them again.
'''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 suggested 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 as the [[Cucumber_(software)#Gherkin_language|Gherkin]] language. 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===
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 — 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.
* 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 |access-date=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 |access-date=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 stories. An example of this style is the [[RSpec]] tool that was also originally developed by Dan North. Specification tools don't use 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 |access-date=12 August 2012}}</ref> An example of a specification for a [[stack (abstract data type)|stack]] might look like this:
'''Specification:''' Stack
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 |access-date=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 – the <code>before</code> section establishes the preconditions that the specification is based on.
The result of test will be:
Hash
should eq {}
includes key
hashes the correct information in a key
== 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 amigos are:
* [[Cynefin framework]]
* [[Concordion]] (Java framework)
* [[Gauge (software)RSpec]]
* [[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==
| 