Introduction
Behavior-Driven Development (BDD) is a software development methodology that emphasizes collaboration between developers, testers, and business stakeholders in the software development process. It is an extension of Test-Driven Development (TDD) and combines the principles of Domain Driven Design (DDD) with the best practices of Agile software development.
BDD encourages the use of a common language, called "ubiquitous language", that can be understood by all stakeholders. It promotes the creation of user stories and acceptance criteria to capture the desired behavior of the system, which are then translated into executable specifications. These specifications guide the development process and serve as an acceptance test suite for the software. This helps in identifying key scenarios for each story and also eradicate ambiguities from requirements.
In BDD, Examples are called Scenarios. Scenarios are structured around the Context-Action-Outcome pattern and are written in a special format called Gherkin.
The scenarios are a way of explaining (in plain english) how a given feature should behave in different situations or with different input parameters.
Because Gherkin is structural, it serves both as a specification and input into automated tests, hence the name “Executable Specifications”.
What is a .feature file and what does it contain?
Feature files are text files with .feature extension, which can be opened by any text editor as well as readable by any BDD-aware tool, such as Cucumber, JBehave or Behat.
Feature files should start with the context of the feature (which is essentially the story), followed by at least one scenario in the following format
Feature: Some terse yet descriptive text of what is desired
In order to realize a named business value
As an explicit system actor
I want to gain some beneficial outcome which furthers the goal
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Scenarios in feature files should focus on the “what” rather than the “how”. The scenarios should be concise and to the point, so that the reader can quickly grasp the intent of the test without having to read a lot of irrelevant steps.
The BDD Process
Discovery
- During the discovery phase, cross-functional teams, including developers, testers, and business stakeholders, come together to explore and define the expected behavior of the system. They create user stories and define acceptance criteria for each story.
Formulation
- In this phase, the acceptance criteria are translated into a formal, executable specification using a BDD language like Gherkin. Gherkin is a structured language that uses plain text to describe scenarios, with keywords such as "Given", "When", "Then", and "And" to define preconditions, actions, and outcomes. .feature files are being created.
Automation
- The executable specifications are then used to create automated tests, typically using a BDD framework such as Cucumber, SpecFlow, or Behat. These frameworks allow the execution of Gherkin scenarios as automated tests, providing a clear and consistent way to validate the system's behavior.
Development
- Developers implement the functionality described in the executable specifications, using the automated tests to guide their work. As the tests pass, the code is considered complete, and the user story is marked as done.
Acceptance
- Once the software has been developed and tested, it is subject to acceptance testing. The product owner or customer performs acceptance testing to ensure that the software meets the acceptance criteria and is ready for deployment. Acceptance testing is performed before changes go to stable branch and environment.
Refinement
- As the system evolves, the team continues to refine and expand the executable specifications. This ongoing process helps ensure that the software continues to meet the needs of the users and stakeholders.
Benefits
Improved collaboration:
- BDD fosters a strong collaboration between developers, testers, and business stakeholders, resulting in a shared understanding of the system's behavior.
Clear communication:
- The use of a common language like Gherkin ensures that everyone involved in the project understands the requirements and expected outcomes.
Faster feedback:
- Automated tests provide fast and consistent feedback on the state of the system, helping to catch issues early in the development process.
Higher quality software:
- BDD helps to minimize the number of defects by focusing on the desired behavior of the system from the beginning.
Reduced time to market:
- By using executable specifications to drive development, BDD reduces the time it takes to deliver a high-quality product.
Best Practices
Encourage collaboration:
- Ensure that all team members are involved in the BDD process, including developers, testers, and business stakeholders.
Keep specifications concise:
- Focus on the most important aspects of the system's behavior and avoid unnecessary detail in the executable specifications.
Use a ubiquitous language:
- Establish a shared language that is understood by everyone on the team and use it consistently throughout the project.
Maintain a living documentation:
- Keep the executable specifications up-to-date and use them as the primary source of documentation for the system.
Continuously refine and expand:
- As the system evolves, continue to refine the executable specifications and add new scenarios to cover changes and new functionality.
BDD Adoption
| Practice | MVP | MVP+ |
|---|---|---|
Establish discovery and formulation practices |
+ |
+ |
Keep requirements and test cases in .feature files |
+ |
+ |
Enable automated acceptance testing as part of the CI process |
|
+ |
Develop automated acceptance test before development |
|
+
|
Roles
| Name | Responsibilities |
|---|---|
|
Participate in joint requirements review session (3Amigos) to create user stories and acceptance steps together. |
Product Owner |
Accept development user stories created in a collaboration of all interested parties (Business, Development, Testing) |
Test Automation Engineer (TAE) |
Automate user stories acceptance tests created in a collaboration of all interested parties (Business, Development, Testing) |
Developer |
Implement or adjust specific product behavior to pass user story acceptance tests created in a collaboration of all interested parties (Business, Development, Testing) |
QA Specialist (Functional SME) |
Perform any additional manual exploratory testing on top of the automated acceptance testing |
