Behavior-driven development

Behavior-driven development (BDD) is an agile software development method centered around collaboration between business and IT professionals that have a stake in finding a solution for a complex problem. The core objective is to achieve a shared understanding of the problem. 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. BDD encourages collaboration among developers, quality assurance experts, and customer representatives in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. BDD is considered an effective practice especially when the problem space is complex. A common misconception regarding BDD is that it supposedly is a refinement of test-driven development (TDD). While it was originally derived from TDD practices, the sole purpose of BDD is to gain a shared understanding of the problem space and find a way to write this down in a Business Language, using Real data, whilst being Intention revealing, Essential and Focused (BRIEF).…

Behavior-driven development (BDD) is an agile software development method centered around collaboration between business and IT professionals that have a stake in finding a solution for a complex problem. The core objective is to achieve a shared understanding of the problem. 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. BDD encourages collaboration among developers, quality assurance experts, and customer representatives in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. BDD is considered an effective practice especially when the problem space is complex. A common misconception regarding BDD is that it supposedly is a refinement of test-driven development (TDD). While it was originally derived from TDD practices, the sole purpose of BDD is to gain a shared understanding of the problem space and find a way to write this down in a Business Language, using Real data, whilst being Intention revealing, Essential and Focused (BRIEF). 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. 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. Some tools specifically for BDD can be used for TDD. The tools automate the ubiquitous language. ===Behavioral specifications=== 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 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. Each user story should, to some extent, follow the structure: Title: An explicit title. Narrative: A short introductory section with the following structure: As a: the person or role who will benefit from the feature; I want: the feature; so that: the benefit or value of the feature. Acceptance criteria:A description of each specific scenario of the narrative with the following structure: Given: the initial context at the beginning of the scenario, in one or more clauses; When: the event that triggers the scenario; Then: the expected outcome, in one or more clauses. 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. It also suggests 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. This format is referred to in Cucumber as the Gherkin language. ===Specification as a ubiquitous language=== BDD borrows the concept of the ubiquitous language from domain driven design. 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. 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. In this way BDD becomes a vehicle for communication between all the different roles in a software project. A common risk with software development includes communication breakdowns between Developers and Business Stakeholders. 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. In addition, having such a ubiquitous language creates a domain model of specifications, so that specifications may be reasoned about formally. 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, for example) and may therefore be processed in some way by a tool that understands the formal parts of the ubiquitous language. Most BDD applications use text-based DSLs and specification approaches. However, graphical modeling of integration scenarios has also been applied successfully in practice, e.g., for testing purposes. ==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. Specification tools don't use user stories as an input format for 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. An example of a specification for a stack might look like this: Specification: Stack When a new stack is created Then it is empty When an element is added to the stack Then that element is at the top of the stack When a stack has N elements And element E is on top of the stack Then a pop operation returns E And the new size of the stack is N-1 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. ==See also== Spec-driven development Specification by example Behat (PHP framework) Cynefin framework Concordion (Java framework) RSpec Gauge Jasmine (JavaScript testing framework) Squish GUI Tester (BDD GUI Testing Tool for JavaScript, Python, Perl, Ruby and Tcl) Use case Fitnesse has been used to roll out BDD ==References==

Text derived from https://en.wikipedia.org/w/index.php?oldid=1378724235 under CC BY-SA 4.0; modifications have been made.