What is BDD, and why are so many teams applying it in their projects? Behavior Driven Development expedites processes, improves visibility, and delivers better results for cross-functional teams. Here's how it works.

What Are TDD and BDD?

BDD, which stands for Behavior Driven Development, was created as an extension of TDD (Test Driven Development). But first, what’s the meaning of TDD? TDD is a development technique that tells us to first write the test cases according to the requirements, before the software is completely developed, then let the software fail so the developer will fix it and make it pass successfully. This concept is also sometimes called “shift left.” When we adhere to TDD, we can assume that, when the developer fixes the test case, the entire requirement has been developed and is working as expected. This sets us up to go further with the next requirement.

A Cross-Functional Team Approach

However, this process applies only for developers, so it’s too technical to be directly applicable for other roles on the team (like quality analysts, testers, product owners, etc.) who are helping to develop the project. With TDD, we know that sections of the code are being tested correctly, but what about the business functionality of the project as a whole? Testers, product owners, and even managers may not have technical knowledge to understand what’s being tested in the system. So how can we make sure everything is working as expected by the end user?

The primary focus of any project is to add value for the customer, not simply test methods and classes that not everybody has the technical knowledge to understand.  TDD is a great development technique for providing better unit testing coverage of the system, but we need a way to bring better understanding to the whole project team to ensure behavioral aspects of the system are working as desired.

This is where BDD comes into the picture! BDD is not only about testing methods and a few pieces of code. It’s about elaborating and describing an entire valuable scenario of the system with a common language every team member will understand.

How BDD Works in a Real Use Case

Let’s imagine we're working with a client who owns a department store. The store has three types of customers:

1. Rewards Members
2. Premium Members
3. VIP Members

For each customer type, we should have different discounts in place for cash payments. For Rewards Members, the discount is 10%. For Premium Members, it’s 20%. For VIP  Members, it’s 30%.

The logic to determine customer type is how long the customer has been registered in the store. So Rewards Members are customers who have been registered in the store for at least 1 year. Premium Members have been registered at least 2 years. VIP Members have been registered 5 years.

Now, let’s look at how we would apply both TDD and BDD to set up discounts.

From the TDD Perspective:

1. Unit test for evaluating the type of customer based on the time the customer registered.
2. Unit test for evaluating how large of a discount will be applied based on the customer type.

Now, from the BDD Perspective:

1. Test case to evaluate when the customer is a Rewards Member, then the discount should be 10%.
2. Test case to evaluate when the customer is a Premium Member, then the discount should be 20%.
3. Test case to evaluate when the customer is a VIP Member, then the discount should be 30%.

TDD vs. BDD

Comparing both perspectives, we can see that individual pieces of logic are being tested in the TDD approach and that these tests are purely technical. Possible logic for this test involves comparing the creation date value of the customer in the system with the current date. This becomes more complex if we also take into account external data, such as fetching all customer information from other third party systems.

From a customer perspective (and also from the perspective of other team members, like testers and product owners), it’s important to know if the “end to end” flow is running successfully, and not only that one part of the system is functioning.

On the other hand, the BDD approach allows us to see real and valuable scenarios that introduce new behaviors within the system. In this approach, the focus is on what the system is able to do and how it responds to different customer types. 

Conclusion

BDD is a great technique when you want to bring more value to other stakeholders, like testers, product owners, and even customers. Behavioral aspects are more intuitive than technical aspects, so BDD helps teams organize projects so that every stakeholder can collaborate and feel more comfortable and confident about the process and results.