"Is this project ready to be deployed?" Every developer is familiar with this question, whether it's asked by a manager or a non-technical stakeholder. Here's how to prepare a good answer.

The main goals of this Snippet are: 

1. NOT to teach you BDD; if you want to learn BDD, I'm providing some links throughout this Snippet so you can learn the concept in more detail, as well as how to code it in your favorite language.
2. Give you a brief intro about what BDD is;
3. Give you a simplified but real life example of BDD usage;
4. Show you how BDD can build trust, make an impact in your project, and even save it, depending on the situation.

Question

Before we explain what BDD is, I will leave a question in the air for you (that we will try to answer later): before deploying your system into production, how do you show non-tech stakeholders that your system is tested (trusted) and ready to go (or not)?

Perhaps you do one of the following:

1. Show all the tests green in your pipeline (unit, integration, performance, acceptance, etc.), and stakeholders trust you because they don't exactly know what you're showing them.
2. Along with your development stories and BA/PDMs (Business Analyst/Product Management) approval, you have some regression/smoke/exploratory test stories before going to production to make sure everything is working.
3. You simply tell stakeholders that it's working and they trust you.
4. Anything else? Tell us in the comments.

What is BDD?

BDD stands for Behaviour Driven Development. It was created in 2003 by Dan North as an improved version of TDD - Test Driven Development.

Briefly, TDD states that you should write your tests before you start implementing your code. This way, you won't miss any scenario and you'll focus your efforts on making those tests pass while implementing your code. 

The biggest flaw of TDD, in my opinion, is that although the concept is awesome, it doesn't give you a clear direction for what you should test and how much you should test. The concept is a little bit vague.

That's where BDD comes in handy. BDD, as the name suggests, is about testing the behaviour. The main premise of BDD is that we use a ubiquitous language, which means a language that everybody understands, tech and non-tech people alike. 

Ok… enough chit chat. Let's see some code. 

Testing Code without BDD

I'll simply present the code in this section and then explain it below.

Properties:

Super class method:

Test:

Testing Code with BDD

Feature File:

Step implementation example:

Context for My Project

Imagine a scenario where a global pandemic affects the global economy, and hence your project loses almost the entire tech team which was there since the beginning. Sounds crazy, right? Yeah I know, nobody is expecting or well prepared for sudden changes like that.

At the time I joined the project, the scenario was: the project had two years of life and less than three months in prod (but it wasn't being fully used yet). It had three devs, myself included. One of these devs had joined six months prior, and the other had joined 2 months prior. There was also one tech lead, who had been there since the beginning, and only one BA/PDM, who had also joined the project very recently and had less context than the devs.

Ok, so now that we have this context... what does BDD have to do with my project?

How BDD Made the Difference

The examples I gave you above were tweaked but were very close to what we faced when we joined the project and how we converted to BDD. Although there were a lot of acceptance tests written, they were practically unreadable by the non-tech stakeholders, and it was hard even for us to say what we had covered. 

As you can see in the test code without BDD section, we had a bunch of json files mapped in our properties, a generic framework to execute the tests based on those json files with some predefined steps, and a simple call to the framework passing the set files we wanted to run based on the configured properties. It was confusing and hard to read.

After creating the feature files with all the scenarios we wanted to test, we implemented those steps and refactored the test code. So we not only had a more readable test, but we also made the values visible, and the steps could be reused independently to create a variety of different scenarios instead of a set of sequential steps like before.

Although thoroughly adhering to BDD would mean that we should have written our tests first, this example shows that you can and should implement BDD in existing code as well, converting your tests to BDD and changing your code accordingly in case there are steps not fully implemented by your code.

Answer

In the beginning of the article I raised the following question: Before deploying your system into production, how do you show non-tech stakeholders that your product/system is tested (trusted) and ready to go (or not)?

My answer to this question is simply: BDD.

Why?

1. The whole team talks in the same language;
2. The team has a clear understanding about the business scenarios covered;
3. It gives the team peace of mind before prod deployments, building trust;
4. It may find bugs that a complex and hard-to-read approach isn't able to discover;
5. It helps in the communication between stakeholders outside the team;
6. As a plus, in our case it was available as a simplified documentation of all the business scenarios we had covered in our complex system.

How to Start Implementing BDD

One of the most famous/used BDD frameworks is Cucumber, and it has support for a variety of languages, including: Java, Javascript, Android, Ruby, Go, C++, Kotlin, Lua, Scala, etc.

Conclusion

BDD can make a big impact on your project, whether you use it in the beginning of the project or adopt it in the middle. It helps you build trust and confidence within your team and all stakeholders. 

It doesn't matter the nature of your project, whether it's just backend, front end, or both -- the bottom line is the same: use BDD. 

Although most teams use BDD in acceptance tests, it can be applied in all levels whenever a behavior exists.

Have you found yourself or anyone you know in a similar situation to mine? Was BDD a game changer for your project too? Tell us about your experience with BDD in the comments below!