Behavior Driven Development

from Wikipedia, the free encyclopedia

Behavior Driven Development ( BDD , German  behavior-driven software development ), also known as Specification Driven Development ( SDD , German  requirement-driven software development ), is an agile software development technique that strengthens the cooperation between quality management and business analysis in software development projects. In behavior-driven development, the tasks, goals and results of the software are recorded in a specific text form during the requirements analysis, which can later be carried out as automated tests and so that the software can be tested for correct implementation. The software requirements are usually written in "if-then" sentences based on the ubiquitous language of domain-driven design . This should facilitate the transition between the language of the definition of the technical requirements and the programming language with which the requirements are implemented.

Behavior Driven Development was first described by Dan North in 2003 as an answer to test-driven development and has evolved since then. Dan North also developed the first framework for implementing BDD, JBehave.

Behavior Driven Development Techniques

Behavior Driven Development consists of the following elements:

  • Strong involvement of stakeholders in the process through so-called outside-in software development. This is focused on meeting the requirements of clients, end users, operations and insiders.
  • Textual description of the behavior of the software and parts of the software using case studies. Use of standardized keywords to mark preconditions, external behavior and desired behavior of the software.
  • Automation of these case studies using mock objects to simulate software parts that have not yet been implemented.
  • Successive implementation of the software parts and replacement of the mock objects.

This creates an automatically verifiable description of the software to be implemented, which allows the correctness of the already implemented parts of the software to be checked at any time.

It is important here that the description does not specify the implementation of the application, but the purpose of the application in the form of application examples.

“In addition to making it harder to focus on important issues, test scripts that describe how over-constrain the implementation. By specifying how something should be done, these tests don't allow developers to find a better solution for the same problem. If specifications only cover what should be done then developers have more freedom to implement good solutions. "

“In addition to being more difficult to focus on important questions, test scripts describing how over-specify the implementation. By describing how something should be done, these tests do not allow developers to find better solutions to the same problem. If specifications only describe what should be done, then developers have more freedom to implement good solutions. "

- Gojko Adzic : Bridging the Communication Gap

Example in the description language Gherkin

In behavior-driven development, the software requirements are described using examples, so-called scenarios. Usually, a certain format is specified for the description of these scenarios so that the automated review of the scenarios can be easily implemented later. One of these formats is the description language "Gherkin". It is also used in various behavior-driven development implementations. This language is available with English keywords (Given, When, Then, And, ...), German (G Given, Wenn, Dann, And, ...) and in other languages.

For example, the requirement "Returned and exchanged goods come back into the warehouse" could be described with the following scenarios:

Scenario 1: Returned goods come back to the warehouse

  • It is given that a customer bought black trousers
  • And then we had 3 black pants in the warehouse,
  • If he returns the pants and receives a voucher for it,
  • Then we will have 4 black pants in the warehouse.

Scenario 2: Goods that have been exchanged are returned to the warehouse

  • It is given that a customer bought a blue skirt
  • And then we got 2 blue skirts
  • And had 3 black skirts in the camp
  • If he exchanges the blue skirt for a black skirt,
  • Then we will have 3 blue skirts
  • And have 2 black skirts in stock.

Each scenario is an example that illustrates a specific behavioral aspect of the application. When discussing the scenarios, the participants should ask themselves whether the results of the scenarios always occur in the given context. This allows further scenarios to clarify the requirement. For example, a specialist could recognize that returned or exchanged goods only come into the warehouse if they are not defective. The scenarios mentioned above would then have to be supplemented accordingly.

The words given, if, and then are used to make the scenarios clear, but they are not essential.

Implementation with mock objects

The defined scenarios can then be provided with automated tests before implementation begins. These test the software while the parts that have not yet been implemented are simulated with the help of mock objects. These mock objects can either be created manually or generated using a mocking framework such as Mockito or EasyMock . The mock objects can be replaced after the corresponding software parts have been completed. These mock objects are also useful for developing unit tests during implementation. This approach supports the creation of small and loosely coupled modules and classes.

Tools

When using behavior driven development, tools ("frameworks") are required for which the behavior of the steps occurring in the scenarios is programmed so that the tool can interpret the scenarios and execute them against the implemented application. The tools themselves are often only suitable for certain programming languages. The best known representatives are JBehave , Framework for Integrated Test (FIT) , FitNesse , Concordion for Java and RBehave , as well as Cucumber for Ruby , Java and JavaScript.

C ++

  • Catch

Ruby

  • RBehave

python

  • aloe
  • Behave
  • radish

.NET

  • NBehave
  • MSpec / Machine.Specifications
  • Specflow and pickles
  • Concordion.NET
  • FSpec
  • NaturalSpec
  • TickSpec
  • SubSpec

Java

  • JBehave
  • Jnario
  • JGiven

JavaScript / TypeScript

  • Jasmine
  • Mocha in combination with Chai and Sinon.js

Scala

  • ScalaTest

PHP

  • Behat
  • Codeception

Go

  • ginkgo

iOS

  • kiwi

Cross-platform

literature

  • David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, ​​Dan North: The RSpec Book. Behavior-Driven Development with RSpec, Cucumber, and Friends . Pragmatic, Lewisville TX 2010, ISBN 978-1-934356-37-1 (English, online [accessed November 12, 2011]).
  • Aslak Hellesoy, Matt Wynne: The Cucumber Book. Behavior-Driven Development for Testers and Developers (=  Pragmatic Programmers ). Pragmatic Bookshelf, Dallas TX u. a. 2012, ISBN 978-1-934356-80-7 (English).

Web links

Individual evidence

  1. ^ A b D. North, Introducing Behavior Driven Development
  2. ^ Dan North et al .: Question about Chapter 11: Writing software that matters. Retrieved on November 9, 2011 (English): “The phrase 'BDD is TDD done well', while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space - around 2003-2004 - this was a valid description. Now it only covers a small part of the BDD proposition. "
  3. ^ Gojko Adzic: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing . Neuri Limited, 2009, ISBN 978-0-9556836-1-9 , pp. 79-80 (English, 284 pages).
  4. Cucumber - Gherkin. Cucumber, accessed November 9, 2011 .
  5. ^ Dan North: What's in a Story? Retrieved November 9, 2011 .
  6. Catch. In: github.com. Retrieved September 25, 2017 (English).
  7. Dan North: rbehave Introducing. June 17, 2007, accessed November 9, 2011 .
  8. Aloe. BDD testing via nose. Retrieved June 19, 2020 (English).
  9. Behave. behavior-driven development, Python style. Retrieved June 19, 2020 (English).
  10. radish. behavior driven development for python. Retrieved January 21, 2013 .
  11. NBehave. In: github.com. Retrieved September 23, 2018 .
  12. Machine Specifications Templates For ReSharper. (No longer available online.) Archived from the original on August 14, 2013 ; accessed on September 1, 2013 (English).
  13. machine / machine.specifications. Machine.Specifications is a Context / Specification framework geared towards removing language noise and simplifying tests. Retrieved September 1, 2013 .
  14. SpecFlow. Binding Business Requirements to .NET Code. Retrieved September 23, 2018 .
  15. Pickles. Living Documentation. Retrieved September 23, 2018 .
  16. ^ Concordion. Retrieved September 23, 2018 .
  17. Fspec. In: github.com. Retrieved September 23, 2018 .
  18. NaturalSpec. In: github.com. Retrieved September 23, 2018 .
  19. TickSpec. In: github.com. Retrieved September 23, 2018 .
  20. John Rudolph: subspec Wiki. In: bitbucket.org. Retrieved September 23, 2018 .
  21. JBehave. Retrieved September 23, 2018 .
  22. Jnario homepage. Retrieved January 30, 2013 .
  23. JGiven. Retrieved March 7, 2015 .
  24. Jasmine - Behavior-Driven JavaScript. Retrieved December 6, 2018 .
  25. Mocha. Retrieved November 2, 2018 .
  26. Chai. Retrieved November 2, 2018 .
  27. Sinon. Retrieved November 2, 2018 .
  28. ScalaTest. Accessed November 26, 2018 .
  29. Behat. Behat - BDD for PHP. Retrieved November 7, 2012 .
  30. Codeception. Retrieved September 23, 2018 .
  31. Ginkgo. A Golang BDD Testing Framework. Retrieved September 23, 2018 .
  32. Kiwi. Retrieved May 20, 2016 .
  33. Squish - GUI Testing with BDD integration. Retrieved January 20, 2017 .
  34. Yulup - Agile requirements engineering using the BDD approach. Accessed August 7, 2017 .