Behavior-driven development: Difference between revisions

Revision as of 08:52, 11 November 2020

Revision as of 05:16, 19 December 2020

Line 1:

{{short description|Agile software development process}}

{{Software development process}}

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 |accessdateaccess-date=25 April 2019}}</ref><ref name="BDD_Def_BehaviourDriven">{{cite web |url=http://behaviour-driven.org/ |title=Behaviour-Driven Development |archiveurlarchive-url=https://web.archive.org/web/20150901151029/http://behaviourdriven.org/ |archivedatearchive-date=1 September 2015 |accessdateaccess-date=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 |accessdateaccess-date=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 |accessdateaccess-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" />

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.

BDD is largely facilitated through the use of a simple [[___domain-specific language]] (DSL) using natural-language constructs (e.g., English-like sentences) that can express the behaviour and the expected outcomes. Test scripts have long been a popular application of DSLs with varying degrees of sophistication. 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>

==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|accessdateaccess-date=6 May 2019 }}</ref> development that makes use of a simple, ___domain-specific scripting language (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.

BDD focuses on:

Line 45:

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 |accessdateaccess-date=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 82:

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

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 |accessdateaccess-date=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 |accessdateaccess-date=7 June 2020}}</ref><ref name="JBehave">{{cite web |url=http://jbehave.org/ |title=What is JBehave?|website=JBehave.org |accessdateaccess-date=20 October 2015}}</ref><ref name="behave">{{cite web |url=http://pythonhosted.org/behave/ |title=behave is behaviour-driven development, Python style |accessdateaccess-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 |accessdateaccess-date=20 October 2015 |url-status=dead |archiveurlarchive-url=https://web.archive.org/web/20150919215413/http://behat.readthedocs.org/en/v3.0/guides/1.gherkin.html |archivedatearchive-date=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 |authorlinkauthor-link=Eric Evans (technologist) |year=2003 |publisher=Addison-Wesley |isbn=978-0-321-12521-7 |accessdateaccess-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 |accessdateaccess-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 |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 105:

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, 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 | accessdateaccess-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 112:

* 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 |accessdateaccess-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 |accessdateaccess-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):

Line 179:

==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 196:

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 |accessdateaccess-date=27 October 2012}}</ref>

<syntaxhighlight lang="ruby">