Behavior Driven Development (BDD) is getting a lot of traction and somewhat becomes a buzzword. The most common bias I see is “I want to automate my tests using BDD”. So let’s make it clear: BDD is not about test automation. It will not ensure the quality of your software. It contributes to it and provides some checks on either the business expectations are met or not. To ensure the quality of your product, you mainly rely on the unit tests and integration tests. As an example this is how the testing pyramid looks like for Hiptest platform:
Behavior Driven Development will help you to develop the right thing, software that matters and deliver value. Having the conversation between all the project stakeholders is where BDD has the biggest impact.
If you are not yet familiar with BDD, I suggest you to read our blogpost “Getting started with BDD” to unterstand the new paradigm it represents and the cultural shift.
Start by the end in mind: the benefits of your feature
When you have a new feature to develop, you should start by focusing on the benefits of this feature. So you answer the WHY. Why should we develop this feature? That’s a great way to drive the conversation on what really matters. In BDD, a feature has a description that provides the context. It is usually written this way:
In order to [get a benefit]
As a [role]
I want [a feature]
Let’s make an example. At Hiptest, we decided to develop an integration with Slack (the real time messaging App) a couple of months back. It was requested by many users to get updates about the testing project directly from slack.
Focusing on value first definitely helped us to narrow down our scenario to the use case that had the biggest impact on the customers. The development team quickly identified 2 use cases that led to 2 different authentication architectures. So impact on the design was important. The 2 options were:
- anyone from the team should get notified in Slack (using a project’s token for the authentication)
- only Hiptest users (having an Hiptest account) should be able to get notified in Slack (using a user’s token for the authentication)
As we wanted to make the biggest impact on teams we’ve chosen option 1 and of course we have challenged that with key customers. The real need was indeed to notify all the team including the guys that didn’t have an Hiptest account.
Having this discussion before starting development was really time saving.
Description of the feature in Hiptest
Now that we have a clear understanding of the benefits of the feature, let’s write our scenario.
Be declarative when writing scenario
With your scenarios, you’ll be able to describe the use cases through examples. At this point, focus on the WHAT not the how! They are 2 ways to write your examples: imperative VS declarative style. With imperative style, scenarios tend to be long with very low level steps that drive the user interface. When using the declarative style of Gherkin syntax, scenarios describes the what, not the how. I strongly recommend the declarative style as they are focused on the business rules.
Ex: Given I am logged in
I don’t care about how we did the login (with a username and password or touchId or…). The thing that matters from a business stand point is that I’am logged in! Detail of the login procedure will be pushed into the step definitions when automating the scenario.
You’ll see that this approach to writing your scenarios will make them shorter and using a business terminology. Make sure that this business terminology is used consistently across all your scenarios. This way it becomes the common language shared by all the team. You’ll need autocompletion to ensure consistency and refactoring capabilities to manage the impacts of changes.
My last suggestion will be to review and refactor your scenarios continuously. These are good practices for your code and the business users should keep the same good habits while writing scenarios.
If you stop there you’ll learn a lot about the feature to be developed and will be able to focus your development efforts on what really matters.
Of course it is great to automate the scenarios and get automated checks. You’ll also unleash the value of living documentation that is really amazing when you get to that point. I’ll write a post on that topic. But stoping after step one with the conversation and manual check is also fine 🙂