Behavior Driven Development (BDD) is a powerful product software development methodology using a collaborative approach that can benefit both business and technical stakeholders. By using BDD, all stakeholders can have a shared understanding of the desired behaviors (features) of an application, and in addition, engineers can implement automated tests from the output that the product team created using BDD, instead of solely relying on themselves to interpretate the requirements on their own.
BDD uses a common language called Gherkin to describe the required behaviors, using a simple syntax that is easy to understand for both technical and non-technical stakeholders. The Gherkin syntax includes Given-When-Then statements that describe the context, action, and expected outcome of a particular behavior. Using this approach in the requirements definition process offers many benefits, including improved communication and collaboration between stakeholders and engineers, and provides additional confidence that what the engineers build meets the stakeholders’ expectations. Additionally, BDD scenarios provide a great reference point for new product and engineering stakeholders to get an initial understanding of the application.
For engineers, another substantial benefit of BDD is that the scenarios can also be used to automatically generate tests with frameworks such as pytest-bdd, Cucumber, SpecFlow, and more. This approach provides tests that are easy to understand and maintain. See the following example (which was taken from this great article on the topic)
Title (one line describing the story)
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: …
In the above example, you can see the Given statement describes the context of the scenario, the When statement describes the action, and the Then statement describes the expected outcome. These Scenarios are usually attached to a user story that can be part of a feature (group of stories), for example user profile, complete with stories for registration, login, logout, update password, and more. These scenarios can then be used to easily generate automated tests using testing frameworks as mentioned in the beginning of this article. I recently used the pytest-bdd package for Python. Here is a similar example:
Scenario: User logs out successfully
Given a user is logged in
When the user clicks the logout button
Then the user should be logged out
Scenario: User cannot log out if not logged in
Given a user is not logged in
When the user clicks the logout button
Then the user should not be able to log out
When saving this to a file with a “.feature” extension, using PyCharm, the following Python code can easily be generated from a simple right click of the file:
import pytest
@pytest.fixture
def logged_in_user():
# Fixture to simulate a logged-in user
yield
# Teardown code to log the user out
@pytest.fixture
def logged_out_user():
# Fixture to simulate a logged-out user
yield
def test_user_logs_out_successfully(logged_in_user):
# Test to ensure that the user logs out successfully
# Simulate clicking the logout button
# Assert that the user is logged out
def test_user_cannot_log_out_if_not_logged_in(logged_out_user):
# Test to ensure that the user cannot log out if not logged in
# Simulate clicking the logout button
# Assert that the user is not able to log out
Which tool (aka IDE) you use, is entirely up to you and also dependent on the programming language you are using. Currently, (I use different languages at different times) I am using PyCharm, and the outstanding support it provides for BDD development. To get started, install PyCharm, pytest, and pytest-bdd and then take a look here for more information.
In short, BDD is a software development methodology that aims to define the desired behavior of the software that the product team wants to create, it uses a common language to describe the scenarios, and can help bridge the communication gap between business and technical stakeholders. These scenarios can also serve as a reference for new stakeholders to read and learn from and can be used by the engineers to generate meaningful automated tests. By adopting BDD, product teams can reduce the risk of miscommunication and haver higher confidence that the application created meets the users’ expectations.