Behavior-Driven Development – BDD

Behavior-Driven Development, BDD agile development, BDD tests, Behavior-Driven Development user story format, cucumber BDD framework

Behavior-Driven Development – BDD – is an agile development process that encourages collaboration among developers, testers and customers using concrete examples to build a shared understanding of how the application should behave, using natural language constructs to express the expected behavior and outcomes that will solve complex business problems and create a higher-quality end product for the users. By using BDD, an application is documented and designed around the behavior a user expects to experience when interacting with it and the following questions are answered:

  • Where to start in the process?
  • What to test and what not to test?
  • How much to test in one go?
  • What to call the tests?
  • How to understand why a test fails?

BDD is an agile software development practice that that closes the gap between business people and technical people by encouraging collaboration across roles to build a common understanding of the problem to be solved, by working in rapid and small iterations to increase feedback and the flow of value and by producing documentation that is automatically checked against the behavior of the system. Behavior-driven development achieves this by focusing collaborative work around concrete, real-world examples that illustrate how the system should behave and BDD teams use those examples to guide themselves from concept to implementation in a process of continuous collaboration.

BDD practices and phases

Behavior-driven development combines, augments and refines practices from TDD and from ATDD:

  • clearly explain the desired business outcomes by applying the 5 Whys principle or the if-then scenario to generate user stories
  • identify a single outcome for every behavior and implement only the behavior that directly contributes to that outcome
  • write tests first and focus on tests which describe the expected behavior of the software, rather than tests which test a unit of implementation
  • translate each scenario into domain specific language (DSL) to ensure accurate communication between the Three Amigos – business, development & testing
  • gather all the behaviors into one set of documentation that is accessible for all the developers, testers and stakeholders

BDD has three phases:

  • Discovery – exploring a story in a structured conversation to ensure that the story will contribute to business outcomes and to ensure shared understanding of what is required by outlining concrete examples of specific scenarios
  • Formulation – rephrasing the examples in a structured language and converting them into executable specifications by following the given-when-then pattern:
    • the scenario (given) – the initial state
    • the event (when) – what happens
    • the outcome (then) – the expected response
  • Automation – turning the executable specifications into automated acceptance tests. Using tools like Cucumber, this is a matter of connecting the tool to the software.

Behavior-Driven Development tests

Behavior-Driven Development suggests that unit tests should be specified in terms of the desired behavior of the unit, written as whole sentences starting with a conditional verb and ordered according to business value. BDD acceptance tests should be written in the user story format of As [a user persona], I want [to perform this action] so that [I can accomplish this goal]. Behaviour-Driven Development acceptance criteria should be written as scenarios in the format of Given [initial context], When [event occurs], Then [ensure some outcomes]

Most popular BDD testing frameworks:

  • Cucumber
  • SpecFlow
  • JBehave
  • Concordion
  • TestLeft
  • FitNesse
  • BeanSpec

BDD structure

  • requirements analysis – precisely define the tasks, objectives and functionalities of the software
  • predefined scenarios – describe the identified functionalities and all the possible scenarios during which the software should respond with a certain answer
  • expected answer for each scenario in a “Given-When-Then” format
    • “Given” describes the software before the test
    • “When” the action during the test
    • “Then” the state of the software after the text

Behavior-Driven Development user story format

Title: An explicit title

Narrative:

  • 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 scenario:

  • 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

Agile development practices