Behavior-Driven Development (BDD) is an agile software testing strategy that emphasizes creating acceptable outputs for end-users. Acceptable behavior is written out in natural language and agreed upon before development begins.
Crucially, for product teams, BDD focuses on making sure the product behaves in such a way that the user is satisfied. We’ll look at how that differs from test-driven development later.
BDD is a collaboration between product managers, developers, and test engineers. Each stakeholder represents areas of development: the reason for the product to exist; the way the project exists; and the verification that the right product exists.
So that all these parties can be fully involved, and so that the verification process is more closely aligned with users, the BDD acceptance criteria are written in natural language that is discussed, agreed upon, and shared between the three parties.
The process of discussing, writing, approving, and recording these tests is iterative and helps product owners better understand how their product should behave under different circumstances.
Talking through behavior-based test cases will often bring to light edge cases or previously unforeseen situations that then need their own acceptable behavior to be established.
The tests are written and approved before any development takes place so that success is a known target.
Following the BDD strategy, the acceptance criteria are agreed upon, then the developers will write code that fails the test. They will then write code that passes the test according to the test criteria. Test engineers verify that the code passes the test, and in the best-case scenario, create automated tests that will be run at each following stage of development so that the system is consistently verified.
Let’s take a look at an example of BDD, as explained by a simple user story with acceptable behavior criteria.
User Story:
As a bank customer
I want my account to log out automatically after 5 minutes of inactivity
So that my account is not vulnerable if I cannot log out or forget to log out.
BDD Acceptance Criteria: The account logs out on both the client page and the server and redirects the client page back to the login page.
There are various frameworks or acceptable templates to create BDD scenarios. They all use natural language to communicate, which must be an agreed shared language so that all members of the team, product managers, developers, and testers have complete clarity.
One of the most common frameworks to communicate BDD acceptance criteria is the Given, When, Then structure. Continuing our banking customer example, the acceptance criteria would then be written as follows:
Given the customer is logged in
When the customer has not performed any action for 5 minutes
Then the customer is logged out of the system
… And redirected to the login page
These frameworks are useful because they clearly give the preconditions where the test is relevant, the triggers for acceptable behavior, and the expected behavior. They are also useful because they help product managers identify gaps.
In the above example, talking through the scenario a product manager would probably realize there needs to be a warning period. Another behavior definition could be added before the test above as follows:
Given the customer is logged in
When the customer has not performed any action for 4 minutes
Then the customer is warned that they will be logged out of the system in 1 minute
… And the warning will count down from 59 seconds to zero seconds
BDD evolved from TDD, bringing product managers and developers together with test engineers to collaborate on concrete examples of acceptable behavior. This ‘acceptable’ behavior is defined according to the user stories that drive the project forward.
Where test-driven development (TDD) focuses on getting correct outputs according to the inputs to smaller software components, behavior-driven development (BDD) focuses on acceptable behavior from the software system from the end-user standpoint.