Behavior-Driven Development (BDD) | David Tzemach
Behavior-Driven Development (BDD) is a software development approach that has evolved from Test-Driven Development (TDD). It promotes a test-first approach where tests are written before the code is implemented. BDD uses a simple human-readable description to transform a user requirement or technical acceptance criteria into a relatively simple format that can be understood by all stakeholders.
The main goal of BDD is to create a shared language between stakeholders that isn’t focused on the implementation itself. This decreases rework, guides development efforts and improves the overall flow between the business and development team.
An important thing to keep in mind is that this approach focuses exclusively on the business value that a specific user should get at the end of development, rather than describing how to use the software or how the software should accomplish its goals.
BDD differs from TDD and ATDD as it is based on a simple language (Gherkin) that creates and promotes shared understanding of the product requirements between the business (often called “non-technical teams”) and the development team.
The Behavior-Driven Development process
The BDD process is based on three core phases that are easily integrated into the Agile environment. We will review each of them based on the following story:
“As a bank customer, I want to be able access the ATM, so I can withdraw up to 100 dollars from my account.”
Phase 1: Defining the Acceptance Criteria
The process starts with the Product Owner, who determines the acceptance criteria of the user story in collaboration with the development team (especially in technical stories).
A classic example of acceptance criteria is:
The customer should withdraw a maximum of $100 per day.
The customer should use their personal password to access their account.
The customer should receive a notification of the new balance in the account.
Now, the same acceptance criteria could also be written in ‘Given-When-Then’ format:
Given a withdrawal limit
When the customer authenticates
Then he can withdraw up to the limit
Phase 2: Formulation of tests
Once the team has committed to a user story and added it to the sprint backlog, it’s time to write the tests based on the expected user behavior.
Example:
Given a withdrawal limit of 100 dollars
When the customer can withdraw money
Then the withdrawal is within the boundaries of 10 (Min) - 100 (Max) dollars
Phase 3: Implementation
The main goal of BDD is to express requirements in simple terms. They reflect the decisions made in the discussion between the different stakeholders to create a shared understanding of intended behavior. Once we achieve this goal, we can initiate the implementation phase for automating the tests.
What you get with BDD testing
There are several reasons why BDD can be a good approach to embrace as part of the Agile development process:
It emphasizes the critical aspects of quality that ensure that the development process meets the requirements that make the product fit to use.
The language used to define the behavior is very simple and written in a clear format that both technical and non-technical stakeholders can understand.
BDD helps the team understand the final behavior of the system from a user point of view and as such, it helps them understand what it takes to deliver it.
Being non-technical in nature, it can be embraced by a wider audience and reduce the learning curve involved in using it.