Examining Behavior-Driven Development
A different approach to programming
After years of working with Object Oriented Programming, my girlfriend recently came to me to talk about Behavior Driven Development. One of her coworkers has been pushing to create test cases using Cucumber and says that BDD is the way to go when programming. While they’re going through training, she has been telling me about what she is learning. That got me thinking maybe BDD would be an interesting topic to cover in a blog post. So, in today’s article, we’ll take a high-level look at what Behavior Driven Development is, more about the process, and a few benefits and drawbacks of using BDD. So, without any further delay, let’s look at what BDD is.
Behavior Driven Development and How it Works
Behavior Driven Development, or BDD, is a methodology where the coding is designed around user experience expectations. BDD is designed this way to improve communication between the business and developers. It’s a way to give more value to the business as the desired can be clearly defined. But this also can add value to the developer.
To improve communications, BDD uses a simple language that is easy to understand for both the machine and also the users involved. Not only the developers but also the business users involved. By keeping the process easy for all parties to understand, you’re allowing better collaboration to help. Business users can get a better idea of the scope and requests this way, but also they can stay involved in the process, so are much more likely to provide helpful details without too many back-and-forth meetings. It also helps to keep developers focused on what the business needs, and allows them to meet all the requirements of the user.
BDD can be several things:
- A language used to define the desired behavior of an application
- A tool for collaboration (between everyone from testers, engineers, and even product managers)
- A system built to automatically test the desired behaviors
To understand more about BDD, let’s learn more about the steps involved.
Approaching Behavior Driven Development
When implementing BDD, the day-to-date activity uses a three-step, iterative process.
- Discovery
- Formulation
- Automation
Before we dive into each, how does the process start? Like all our other Agile projects, we start with a User Story. These user stories include a lot of our details, which leads to the first step: Discovery.
The end goal is to get efficient and valuable software working for the end user. To flesh out the requirements, we work through Discovery. In BDD, a lot of Discovery focuses on meeting with all people involved. This helps to find realistic deadlines, the precise details and features required, as well as the realism aspect from developers. These conversations tell the business users what the developer can do, and allows the business to give their perspective and needs to the developer. The meetings also aid to minimize the number of back-and-forth conversations. Overall, Discovery tries to save time and become a more efficient process for all parties involved.
While the business users and developers are deciding what needs to be created for the final product, you should also consider your testing process. This gives you a chance to consider the test scenarios in simple terms that everyone can understand. It also allows you to get a detailed description of what the actual test will look like, how to test the application, and what the expected behavior of the application will be. With all these conversations, you may also want to think of real-world examples to gain more perspective of the user. This keeps your project within scope while also determining a more realistic approach.
With Discovery providing at least one valuable example, we’re ready to move on to Formulation. For this step, the example(s) can be converted into structured documentation. This helps to ensure there is a true understanding of the requirements. However, BDD uses a language that can be easily understood by both computers and humans. This helps to gain feedback from the whole team in a shared vision of what is being built. It also helps to automate the example(s) to guide the team’s development. With a shared language for talking to the system, the collaboration helps to use problem-domain terminology down to the code. This just means that there is a greater range of visibility and understanding for everyone involved, right down to the code being written.
With Formulation being finished, we’re ready for the final step: Automation.
Because there is detailed documentation, you can use that to write your Automated tests. These help to guide the development of the code. As a test is written, it is expected to fail because the features have yet to be implemented. Essentially, you use the tests to drive the development of the code. Because you’re going down a list of tests, you also have a clear path for completion and time management. As each test is completed, you can get feedback from the team, which helps with roadblocks and the continuation of development. The feedback should be rapid and repeatable, which helps reduce the burden of performing manual regression testing.
The goal of using these steps is to keep changes controlled, meaning both small and able to iterate rapidly. As you add more, you need to go through the whole process again to gain all the necessary details, but you are also gaining more value to the final product each time.
Below are the outlined steps:
Now that we know more about the BDD process, let’s take a look at some benefits.
Benefits of Behavior Driven Development
Although this is not an all-encompassing list, here are a few benefits of using Behavior Driven Development:
- A shorter learning curve, as BDD, uses a simple language for an easier learning curve no matter what skill level the user has
- Because BDD is a nontechnical process, there is much higher visibility as it can reach a wider audience
- Clear objectives can be met, so BDD requirements lead to less rework from misinterpretations
- BDD also has strong collaboration, as developers are not the only users who can learn the simple language but also testers, product owners, and so on
There are many more benefits, but these were just a few important ones. Let’s also take a look at a few disadvantages.
Disadvantages of Behavior Driven Development
Like the benefits, this will be a list of only a few drawbacks, but here are a few important ones to consider when using Behavior Driven Development:
- If the requirements are not clear and precise, BDD may not be effective
- Because BDD is Agile, it does not work well (or is not compatible) with a Waterfall approach
- Although BDD uses testers, the people testing should have the sufficient technical expertise
- To work with BDD, the user should have prior exposure to TDD (Test Driven Development) concepts
Now that we have looked at both a few advantages and disadvantages of BDD
An Example of BDD
You’ve heard about how easy the language is, and how understandable for both developers and business users, but now I thought it was time to share an actual example. The most common formula for BDD is a Given-When-Then format:
Given, the starting logic, or initial context
When, the action which is performed
Then, the expected outcome of the action
When trying to figure this all out, I found an example on Inviqa from authors Konstantin Kudryashov, Alistair Stead, and Dan North that summed it up in a very simple way to understand.
First, they started with the Feature example, which gave a few documented details:
Feature: returned items go back to stock
In order to keep track of stock
As a store owner
I want to add items back to stock when they are returned
Next, they provided two examples of scenarios that could fit the feature:
Example: Refunded items should be returned to stock
Given a customer previously bought a black sweater from me
And I currently have three black sweaters left in stock
When he returns the sweater for a refund
Then I should have four black sweaters in stock
Example: Replaced items should be returned to stock
Given that a customer buys a blue garment
And I have two blue garments in stock
And three black garments in stock
When he returns the garment for a replacement in black
Then I should have three blue garments in stock
And two black garments in stock
I thought those examples were very helpful, so check out their article for more detailed descriptions of their guide to understanding BDD.
Conclusion
In today’s article, we talked a little about Behavior Driven Development (or BDD). We discussed how it is a methodology for better communication between developers and business users, all the steps involved, and also a few benefits and drawbacks. We also took a look at an example of how to use BDD.
Although I’m not saying BDD is better than OOP (Object-Oriented Programming), or vice versa, I thought it was still interesting to learn about. If you have any experience using BDD, please let me know in the comments. I would love to hear about your projects and experiences. Otherwise, I hope you found this article interesting, and that maybe you even learned something new from it. Until next time, cheers!
Read all my articles for free with my weekly newsletter, thanks!
Want to read all articles on Medium? Become a Medium member today!
Check out some of my recent articles:
References:
