"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:
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:
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.
I'll simply present the code in this section and then explain it below.
Properties:
Super class method:
Test:
Feature File:
Step implementation example:
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?
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.
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?
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.
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!