Behavior-driven development

Last updated

Behavior-driven development (BDD) involves naming software tests using domain language to describe the behavior of the code.

Contents

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. [1] [2] It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. [3] BDD is considered an effective practice especially when the problem space is complex. [4]

BDD is considered a refinement of test-driven development (TDD). [1] [5] [6] [ vague ] [7] [8] 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. [1] [7]

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. [5] Some tools specifically for BDD can be used for TDD. The tools automate the ubiquitous language.

Overview

BDD is a process by which DSL structured natural language statements are converted to 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 [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, QA and non-technical or business participants in a software project. [9]

Principles

BDD suggests that software tests should be named in terms of desired behavior. [5] [7] 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. [5] Within BDD practice, this is referred to as BDD being an "outside-in" activity.

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.

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: [5]

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. [5] 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. [10] 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. [5] [7] 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. [11] 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. [11] In this way BDD becomes a vehicle for communication between all the different roles in a software project. [5]

A common risk with software development includes communication breakdowns between Developers and Business Stakeholders. [12] 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. [5] In addition, having such a ubiquitous language creates a domain model of specifications, so that specifications may be reasoned about formally. [13] 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. [14]

Specialized tooling

Much like TDD, BDD may involve using specialized tooling.

BDD requires not only test code as does TDD, but also a document that describes behavior in a more human-readable language. This requires a two-step process for executing the tests, reading and parsing the descriptions, and reading the test code and finding the corresponding test implementation to execute. This process makes BDD more laborious for developers. Proponents suggest that due to its human-readable nature the value of those documents extends to a relatively non-technical audience, and can hence serve as a communication means for describing requirements ("features").

Tooling principles

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.

The ubiquitous language allows business analysts to document 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. [15] The exact implementation of behavioral requirements varies per tool, but agile practice has come up with the following general process:

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. [5] [16] 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. [16]

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. [17]

The three amigos are:

See also

Related Research Articles

<span class="mw-page-title-main">Acceptance testing</span> Test to determine if the requirements of a specification or contract are met

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.

<span class="mw-page-title-main">Software testing</span> Checking software against a standard

Software testing is the act of checking whether software satisfies expectations.

Unit testing, a.k.a. component or module testing, is a form of software testing by which isolated source code is tested to validate expected behavior.

The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

In software and systems engineering, the phrase use case is a polyseme with two senses:

  1. A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
  2. A potential scenario in which a system receives an external request and responds to it.

Test-driven development (TDD) is a way of writing code that involves writing an automated unit-level test case that fails, then writing just enough code to make the test pass, then refactoring both the test code and the production code, then repeating with another new test case.

<span class="mw-page-title-main">Requirements analysis</span> Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating, and managing software or system requirements.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

Web development is the work involved in developing a website for the Internet or an intranet. Web development can range from developing a simple single static page of plain text to complex web applications, electronic businesses, and social network services. A more comprehensive list of tasks to which Web development commonly refers, may include Web engineering, Web design, Web content development, client liaison, client-side/server-side scripting, Web server and network security configuration, and e-commerce development.

Agile software development is an umbrella term for approaches to developing software that reflect the values and principles agreed upon by The Agile Alliance, a group of 17 software practitioners in 2001. As documented in their Manifesto for Agile Software Development the practitioners value:

In software testing, test automation is the use of software separate from the software being tested to control the execution of tests and the comparison of actual outcomes with predicted outcomes. Test automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or perform additional testing that would be difficult to do manually. Test automation is critical for continuous delivery and continuous testing.

Extreme programming (XP) is an agile software development methodology used to implement software systems. This article details the practices used in this methodology. Extreme programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.

Model-driven engineering (MDE) is a software development methodology that focuses on creating and exploiting domain models, which are conceptual models of all the topics related to a specific problem. Hence, it highlights and aims at abstract representations of the knowledge and activities that govern a particular application domain, rather than the computing concepts.

RSpec is a computer domain-specific language (DSL) testing tool written in the programming language Ruby to test Ruby code. It is a behavior-driven development (BDD) framework which is extensively used in production applications. The basic idea behind this concept is that of test-driven development (TDD) where the tests are written first and the development is based on writing just enough code that will fulfill those tests followed by refactoring. It contains its own mocking framework that is fully integrated into the framework based upon JMock. The simplicity in the RSpec syntax makes it one of the popular testing tools for Ruby applications. The RSpec tool can be used by installing the rspec gem which consists of three other gems, namely rspec-core, rspec-expectation and rspec-mock.

The INVEST mnemonic for Agile software development projects was created by Bill Wake as a reminder of the characteristics of a good quality Product Backlog Item or PBI for short. Such PBIs may be used in a Scrum backlog, Kanban board or XP project.

Twist is a test automation and functional testing solution built by Thoughtworks Studios, the software division of ThoughtWorks. It uses Behavior Driven Development (BDD) and Test-driven development (TDD) for functional testing of the application. It is a part of the Adaptive ALM solution consisting of Twist for Agile testing by ThoughtWorks Studios, Mingle for Agile project management and Go for Agile release management.

Cucumber is a software tool that supports behavior-driven development (BDD). Central to the Cucumber BDD approach is its ordinary language parser called Gherkin. It allows expected software behaviors to be specified in a logical language that customers can understand. As such, Cucumber allows the execution of feature documentation written in business-facing text. It is often used for testing other software. It runs automated acceptance tests written in a behavior-driven development (BDD) style.

Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements. It is applied in the context of agile software development methods, in particular behavior-driven development. This approach is particularly successful for managing requirements and functional tests on large-scale projects of significant domain and organisational complexity.

Acceptance test–driven development (ATDD) is a development methodology based on communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as specification by example (SBE), behavior-driven development (BDD), example-driven development (EDD), and support-driven development also called story test–driven development (SDD). All these processes aid developers and testers in understanding the customer's needs prior to implementation and allow customers to be able to converse in their own domain language.

<span class="mw-page-title-main">Behat (software)</span>

Behat is a test framework for behavior-driven development written in the PHP programming language. Behat was created by Konstantin Kudryashov and its development is hosted on GitHub.

References

  1. 1 2 3 "Behaviour-Driven Development". Archived from the original on 1 September 2015. Retrieved 12 August 2012.
  2. ↑ Keogh, Liz (2009-09-07). "Introduction to Behavior-Driven Development". SkillsMatter. Archived from the original on 2021-02-25. Retrieved 1 May 2019.
  3. ↑ John Ferguson Smart (2014). BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle. Manning Publications. ISBN   9781617291654.
  4. ↑ Tharayil, Ranjith (15 February 2016). "Behavior-Driven Development: Simplifying the Complex Problem Space". SolutionsIQ. Retrieved 15 February 2018.
  5. 1 2 3 4 5 6 7 8 9 10 Haring, Ronald (February 2011). de Ruiter, Robert (ed.). "Behavior Driven development: Beter dan Test Driven Development". Java Magazine (in Dutch) (1). Veen Magazines: 14–17. ISSN   1571-6236.
  6. ↑ Solis, Carlos; Wang, Xiaofeng (2011). "A Study of the Characteristics of Behaviour Driven Development". 2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications. pp. 383–387. doi:10.1109/SEAA.2011.76. hdl: 10344/1256 . ISBN   978-1-4577-1027-8. S2CID   3392536.
  7. 1 2 3 4 Bellware, Scott (June 2008). "Behavior-Driven Development". Code Magazine. Archived from the original on 12 July 2012. Retrieved 1 May 2019.
  8. ↑ Liz Keogh (June 27, 2011). "ATDD vs. BDD, and a potted history of some related stuff" . Retrieved 6 May 2019.
  9. ↑ "The RSpec Book – Question about Chapter 11: Writing software that matters". Archived from the original on 2009-11-07. Retrieved 2009-08-09.
  10. ↑ Mabey, Ben. "Imperative vs. Declarative Scenarios in user stories". Archived from the original on 3 June 2010. Retrieved 19 May 2008.
  11. 1 2 Evans, Eric (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley. ISBN   978-0-321-12521-7 . Retrieved August 12, 2012.
  12. ↑ Geneca (16 Mar 2011). "Why Software Projects Fail" . Retrieved 16 March 2011.
  13. ↑ Mahmudul Haque Azad (6 Feb 2011). "Say Hello To Behavior Driven Development" . Retrieved 12 August 2012.
  14. ↑ Lübke, Daniel; van Lessen, Tammo (2016). "Modeling Test Cases in BPMN for Behavior-Driven Development". IEEE Software. 33 (5): 15–21. doi:10.1109/MS.2016.117. S2CID   14539297.
  15. ↑ Adam Craven (September 21, 2015). "Fundamentals of Enterprise-Scale Behaviour-Driven Development (BDD)" . Retrieved 14 January 2016.
  16. 1 2 Roy Osherove (October 4, 2008). "BDD: Behavior vs. Spec Frameworks" . Retrieved 12 August 2012.
  17. ↑ "What are the Three Amigos in Agile?". Agile Alliance. 2016-06-16. Retrieved 2019-06-10.
  18. ↑ Ketil Jensen (December 13, 2009). "BDD with Scenario tables in Fitnesse Slim". Walk the walk. Wordpress. Retrieved 12 August 2012.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.