Behavior-driven development: Difference between revisions

Revision as of 02:09, 14 November 2024

Latest revision as of 00:21, 12 March 2025

(3 intermediate revisions by one other user not shown)

Line 7:

Proponents claim it encourages collaboration among developers, quality assurance experts, and customer representatives in a software project.<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=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 }}</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="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]].

Line 13:

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

Line 27:

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>

== Principles ==