Behavior-driven development: Difference between revisions

Revision as of 18:53, 27 June 2023

Revision as of 02:02, 28 June 2023

Line 20:

At its heart, BDD is about rethinking the approach to [[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|title=How to sell BDD to the business - &#124;{{pipe}} SkillsCast|url=https://skillsmatter.com/skillscasts/923-how-to-sell-bdd-to-the-business|access-date=2023-02-07|website=How to sell BDD to the business - &#124;{{pipe}} SkillsCast|language=en}}</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>

Line 26:

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&#61;=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]</ref> which was later integrated into the [[RSpec]] project.<ref name="rbehave-integ">{{Cite web|title=RSpec Adds Eagerly-Awaited RBehave Functionality for Integration Testing|url=https://www.infoq.com/news/2007/10/RSpec-incorporates-RBehave/|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.

Line 87:

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