The philosophy
Behavior Driven Development (BDD) is an approach that consists on defining the behavior of a feature through examples in plain text. These examples are defined before the development starts and are used as acceptance criteria. They are part of the definition of done. That's a very powerful approach that we use at Hiptest in our development process. These examples support the conversation and help the cross functional team (marketing, product owner, developer, user...) to create a shared understanding of what should be developed. That's a great way to minimize waste and avoid development of features that nobody want or that do not meet the business expectations.
These concepts are quite simple and were initially formalized by Dan North. But implementing them is much harder.
A cultural shift
In the past decades, software development lifecycle has been structured with silos. Every silo comes with its repository.
Agile development has changed the game and broken the silos. There is also a lot of buzz around agile testing. But BDD is more than just testing. Trying to match with the concepts of the old world is useless. It is like applying equations of the classical physics to the quantique world. When doing BDD, specifications and tests become two sides of the same coin. You define your specification by examples and at the same time you get your tests. These specifications become executable when the examples are automated.
And this new paradigm changes everything. You'll face many questions further down the road towards BDD. If you want to go deeper on the theory and cultural shift, I suggest the following reading: "Specification by Example" by Gojko Adzic
Using BDD with gherkin syntax
Gherkin is plain-text language with a little extra structure designed to be easy to learn by non-programmers. It allows concise description of examples to illustrate business rules in most real-world domains. One of the big advantage is that it clearly highlights the intent of the example/test.
Follow these basic steps to begin using BDD and Gherkin syntax:
- Start with your user stories.
- As a team, go through your user stories and write BDD scenarios using the keywords GIVEN, WHEN, and THEN (AND, BUT can be used as well)
- GIVEN is your setup; for example, "GIVEN the credit card is valid"
- WHEN is your action; for example, "WHEN I request $50"
- THEN is your assertion; for example, "THEN the ATM should dispense $50"
- Capture the BDD scenarios in a location that is public for everyone to see. Hiptest is a good choice :)
- Automate your BDD scenarios.
- Implement the features
- Run the automated BDD scenarios to show the feature is completed
- Repeat
Here is a sample Gherkin document:
Feature: Account Holder withdraws cash
Scenario: Account has sufficient funds
Given the account balance is $100
And the card is valid
And the machine contains enough money
When the Account Holder requests $20
Then the ATM should dispense $20
And the account balance should be $80
And the card should be returned
Let's create a first example!
For this step by step tutorial, we'll use Hiptest and a default project that is created when signing up to the platform.
If you want to use another project, make sure the BDD mode is activated.
Step 1: create a feature
Features are managed with folders to better organize your project.
A feature has a description that provides the context. It is usually written this way:
As a [role]
I want [feature]
So that [benefit]
A feature contains one or many scenarios that describe its behaviors.
Step 2: write a scenario
By getting the business users, the analysts, the testers and the developers to adopt this vocabulary of “given/when/then”, lots of ambiguities fall away and conversations become more efficient.
Let's write our first step: given the account balance is "$100"
Hiptest interprets and highlights the keyword Given. It will also consider $100 as a parameter because of the double quotes "my parameter value". This way you'll be able to reuse the same step in the future with a different value.
And after a couple of seconds we get the following scenario.
Note that the step editor comes along with an autocompletion that enables you to reuse existing steps and design scenarios with a consistent business terminology.
Step 3: use scenario outline with examples
Cloning scenarios to use different values can quickly become tedious and repetitive. Scenario outlines allow you to more concisely express these examples through the use of parameters and datatable. Using our previous scenario we can create 3 examples:
We've created our first feature and scenario with Hiptest. We can share this scenario with all the team members to discuss what should be developed. This way we create a shared understanding.
That's it, a brief introduction to BDD. To sum up, the main idea behind BDD is that it's driven to prevent communication gaps, getting everyone in the team communicating more often, better and based on real world examples and not on abstract and imperative requirements. The best way to learn is to practice :) So let's get started!
The next post (Part 2) will focus on the key practices to keep your scenarios readable and maintainable over the time.
Download Parkeon's success story : Using Behavior Driven Development on a huge ticketing system
