Widely known in the tech world by its abbreviation BDD or by the nickname “Specification by Example”, Behavior-Driven Development is generally defined as “a methodology for developing software through continuous example-based communication between developers, QAs, and BAs.” Created by a man named Dan North, BDD is his answer to the frustration of not being able to explain clearly when developers wanted to know where to start, what not to test, how much to test, what to call the tests, and how to understand why a test fails. Stemming from Test Driven Development (TDD) and Acceptance Test-Driven Development (ATDD), this methodology is used to bring agility, concrete communication, and a shared understanding of objectives between teams, technical and non-technical.
Essentially the collaborative process of describing, in a very direct example-driven way, a set of behaviors that can be expected from a system–ultimately, the outcome is that all stakeholders are able to have powerful conversations about what the software should do. On top of that, when implemented correctly, everyone in all teams will understand the functionality of deliverables without confusion and be able to identify key results before the development process even begins. In the following article, we will explore the ins and outs of BDD as well as examples of how to implement it into your organization’s software development management methodology.
Acceleration of TDD and ATDD through BDD
In order to understand BDD, you must first be introduced to the meanings of TDD and ATDD as well as how they are used. Following that, you must then understand how BDD accelerates these two methodologies by combining their basic principles into one powerful software development process.
TDD “refers to a style of programming in which three activities are tightly interwoven: coding, testing (in the form of writing unit tests), and design (in the form of refactoring).” When this methodology is in use, a developer must first define a test set for a specific unit, then purposely make it fail, then deploy the unit, followed by defining if the unit was a success. A very key part of the success of BDD, a programmer should know and work within the TDD structure before learning or implementing BDD.
ATDD “involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality. The collaborative discussions that occur to generate the acceptance test is often referred to as the three amigos – representing the three perspectives of customers (what problem are we trying to solve?), development (how might we solve this problem), and testing (what about…).” Each test within this methodology should be written in a “given, when, then” style or if-then format, like below:
Given [initial context]
When [event occurs]
Then [ensure some outcomes]
With the first focus on reducing overall development time as well as the number of bugs found via tests on all requirement levels and stronger codebases, the second focus zeroes in on simplifying communication via a Domain-Specific Language format and the interworking of every end result perspective, when combined we get BDD. Now, taking what we know from above–that BDD is an example-driven communication methodology used to talk about application behaviors–at its core, BDD basic principles use the conversation structure that even non-developers can understand from ATDD in conjunction with a narrowed down TDD testing focus aimed at behavior specifics that are best described in business-driven logic.
The 2 Basic Principles
1. User Stories
Plain language written scenarios that describe the intent, the who, and the what should happen in order to achieve the requirements of the unit. Within BDD, User Stories need to be very specific and always in whole sentences including the name/feature. When introducing the method, Dan North stated that “Developers discovered it could do at least some of their documentation for them, so they started to write test methods that were real sentences. What’s more, they found that when they wrote the method name in the language of the business domain, the generated documents made sense to business users, analysts, and testers.” Ideally using the word “should” and in an if-then format, BDD technically calls for no specific scenario format. However, many experts, including Dan, suggest that your organization work with one standardized format. That way teams can modify, explore, and expand without any issue, now and in the future.
Dan North’s User Story Format
Title (one line describing the story with should)
Narrative:
As a [role] I want [feature] So that [benefit]
Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title
Given [context] And [some more context]…
When [event] Then [outcome] And [another outcome]…
Scenario 2: …
To help you better understand how it looks, with slight variations of format, here is an API test example taken from Guru:
Feature: Test CRUD methods in Sample REST API testing framework
Background:
Given I set sample REST API URL
Scenario: POST post example
Given I Set POST posts API endpoint
When I Set HEADER param request content type as “application/JSON.”
And Set request Body
And Send a POST HTTP request
Then I receive valid HTTP response code 201
And Response BODY “POST” is non-empty.
Scenario: GET posts example
Given I Set GET posts API endpoint “1”
When I Set HEADER param request content type as “application/JSON.”
And Send GET HTTP request
Then I receive valid HTTP response code 200 for “GET.”
And Response BODY “GET” is non-empty
Scenario: UPDATE posts example
Given I Set PUT posts API endpoint for “1”
When I Set Update Request Body
And Send PUT HTTP request
Then I receive valid HTTP response code 200 for “PUT.”
And Response BODY “PUT” is non-empty
Scenario: DELETE posts example
Given I Set DELETE posts API endpoint for “1”
When I Send DELETE HTTP request
Then I receive valid HTTP response code 200 for “DELETE.”
2. Common Languages
As we have stated numerous times throughout this article, and can not stress enough, BDD relies heavily on the use of language that every member of your team can understand. Domain-Specific Language (DSL) is what makes each scenario readable by business partners, the ones who are commissioning the software and tests in the first place, wanting a specific behavior to occur. It works to remove the need to explain, on both technical and non-tech ends, how a behavior is implemented and in return makes less confusion throughout the process.
Tools
In order to maximize time and outcomes, BDD is supported by tools that automate tests. Closely linked to the DSL that is defined by your organization, these tools include Cucumber, which can understand Gherkin while supporting writing specifications for 30 spoken languages. When in use, such tools automatically execute common language specifications.
Launch Behavior-Driven Development In Your Organization
No matter where your organization is in its software development management journey–using agile methods, waterfall, or something else–implementing this methodology yields a higher gain than risk value. If the use of the method does not suit your needs, you can simply go back to writing test requirements the way you have been doing it. There is no undoing anything.
To begin, first, ensure your developers are working within and understand TDD. If they are not, they will need to start a training period to develop skills within this style of programming. Once your developers are on board, you can implement the basics of BDD to your entire organization. Again, a training period will need to take place. During this time Developers, QA, and BA teams need to be taught how to read and understand your chosen DSL and documentation method. Start with just one project to see how it all works is best. Be aware that this methodology requires specifications before development and constant outside feedback from users, customers, and domain experts. However, when implemented successfully, you will reduce regression and improve goal communication.
