Behavior Driven Development, also known as BDD, is a software development process that can be utilized to help your team deliver value and build more reliable software. As you may have guessed, BDD incorporates various aspects from Agile and lean practices, and more importantly, TDD and DDD.
Just like in TDD, BDD uses tests to help specify, design, and verify application code, therefore reducing the the defect count and improving code maintainability. But what makes BDD different from TDD?
BDD differs from a simple unit test because its tests focus on the actual behavior of the system based on predefined scenarios, making the tests easier to understand and more meaningful. This results in the production of higher quality code.
So, why should you start implementing BDD? Here's a quick list of reasons why:
- Improves team communication
Among the many practices of BDD, communication can be seen as the key that binds it all together. It allows business analysts to elaborate and refine requirements together with QAs and Developers, resulting in more efficiency.
- Creates structured scenarios
As a result of the communication between the BAs, developers, and QAs, a structured scenario is created and used as a guide for developers to create code, and for QAs to create and automate tests. Gherkin is the formula typically used for this.
- Tests automation - Executable Specifications
Executable Specifications are automated tests that verify how the application delivers a specific business requirement. These tests produce reports that can be understood by everyone involved in the project, as well as serve as validators, documentation, and tools for communication.
- Focuses on features that deliver business value
Teams practicing BDD will engage with stakeholders to try and understand the core business goals, this way the features delivered will be those that aggregate more value for the end-user.
- Creates living documentation
Reports produced by Executable Specifications are a form of product documentation and require little to no maintenance. They're written using familiar vocabulary as well as provide insight into the current application status and project progression.
- Results in faster releases
Testers will no longer need to execute long, manual tests and will have more free time to create automated acceptance tests, thus increasing the velocity of the delivery.
- Allows easier and safer changes
The living documentation clarifies what the application does for the end-user so that they're able to implement improvements and changes more easily. The automated tests and unit tests also decrease the risk of regressions caused by changes in the application.
- Results in reduced costs and waste
Since BDD focuses on delivering value and avoiding waste, less code and documentation are required, thus reducing the overall cost.
So far, I've explained why you should use BDD, but what about why you shouldn't? There are certain cases where using BDD can be counterproductive. Here are some issues that can arise when implementing BDD:
- Lack of business engagement
In cases where stakeholders are not willing to engage and collaborate with the team, it is difficult to reap the benefits of BDD implementation.
- Lack of experience with Agile
If the stakeholders and/or the team are not used to working in an Agile environment, BDD probably won't be as effective as it could be.
- “Silo” development
Development teams, business analysts, and owners are used to working in isolation from each other; therefore, effort is required in order to change this culture so that BDD can work.
- Poorly written tests
Creating and maintaining automated tests for complex systems requires skill, but most teams starting with BDD probably don't have this skill figured out yet. That can cause tests to be fragile as well as a lot of issues in the software engineering process as a whole.
- Teams that are too technical
When business analysts and owners are too focused on technical aspects, BDD most likely will not be fully adopted, even though some of its practices may still apply.
So, should you use BDD? Maybe! It depends on the team's knowledge, the company culture, and the team's openness to change. However, also keep in mind that you can always apply certain BDD practices to improve your quality of work!