Getting started with Behavior Driven Development

Jump Right In

This tutorial is the perfect starting point for product owners, testers and developers who want to learn the fundamentals of Behavior Driven Development (BDD). It will be walking you through a step-by-step process including the tools, major concepts, and best practices that will ease your path towards BDD.

By the end of this tutorial you’ll know how to:

Describe business needs using examples with Gherkin language
Use your scenarios to drive development
Implement step definitions to automate your tests
Integrate BDD as part of your CI process
Keep your test suite fast and lean with refactoring

If you are not familiar yet with BDD you should start by reading this free ebook as introduction: Kick start and scale BDD.

Prerequisites

To follow this tutorial, you will need a few prerequisites:

Create a CucumberStudio account (if you have not yet) to write your Gherkin scenarios: https://studio.cucumber.io/users/sign_up

[OPTIONAL] If you want to automate your scenarios and integrate with a CI tool, you need first to take the following tutorial: CI in 5 minutes flat. For this second tutorial, you need:

a GitHub account
a computer setup to execute tests (you will be able to choose your preferred language later on)
a text editor (and preferably a code editor)
git installed on your machine
hiptest-publisher installed on your machine to generate executable scripts for different frameworks like Cucumber, SpecFlow, Behave, JBehave, Jasmine and many more.

Ready? Let’s get started!

Describe business needs using examples with Gherkin language

For this tutorial, we are going to use a simple application almost everyone is familiar with: a coffee machine. You start it, you ask for a coffee and you get it, sometimes. But most of times you have to add water or coffee beans, empty the coffee ground… If you have an automatic expresso machine at work or at home you know how it goes. :)

So for this first step you will work on a new feature of this application: descaling the machine. Before that, you should get familiar with the application and project.

You will find the expresso machine application here. You can play with it.

To see the corresponding BDD scenarios and living documentation, generate your sample project in CucumberStudio. This feature is available from the home page displaying the projects list.

Create new Hiptest sample project

You can see that you already have existing scenarios describing the behavior of existing features like: Simple use:

Simple use Hiptest scenario

Now that you have discovered the application and BDD project, here is a new business need that have to be implemented and tested: “After 500 coffee the machine requires to be descaled.”

Writing a scenario and automate it as part of the definition of done, will help the developers to focus on the business needs while implementing the feature. Now let’s create your very first scenario for this project:

Open the project “Coffee Machine” in CucumberStudio, once open you’ll be on the project dashboard displaying different metrics
In the left panel, select “Scenarios”
In the folder tree view, select the folder “Display errors”
Create a new folder “Descaling”
Finally, create a new scenario named “Descaling is needed after 500 coffees“ inside the folder you just created.

Now you can create the steps for the scenario. Try to figure out what would be the steps before looking at the solution.

Ok. Now look at the video to see a possible scenario for this feature.

Note that we mainly reuse existing steps and create a new one. It is important to create scenarios using a consistent business terminology. It helps the team to create a common language for the application or business domain.

Here is how your scenario should look like at the end of this step.

Descaling Hiptest scenario

Note: when writing the scenario, use an “=” sign in front of 500. This will tell CucumberStudio that it should consider the numeric value 500, not the string “500”.

Good practices:

They are two 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 describe the what, not the how. We strongly recommend the declarative style as they are focused on the business rules.

You will see that this approach to write 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 will need autocompletion to ensure consistency and refactoring capabilities to manage the impacts of changes.

Wrap up

Having the conversation with all the stakeholders to create a shared understanding of the feature is where BDD deliver the biggest impact. You can run discovery workshops to elicit requirements from your stakeholders and capture features’ behavior with scenarios.

Make sure your scenarios are designed with a consistent business terminology. That is the key for a better understanding, for maintenance and automation.

Use your scenarios to drive development

The dev team will use your scenario as input to drive the implementation of the feature. You can check the web application here.

If you look at the code, you can notice that the descaling feature has already been implemented, so there’s not much work to do here. Good job!
Now that the feature has been implemented, it is time to use the examples you wrote to make sure it works as expected.

You can stop this tutorial here if you just want to execute your scenarios manually. That’s fine. CucumberStudio provides test management capabilities to help you track manual test results once the implementation is available. Check this short video for manual execution:

If you want to automate your scenarios and integrate with your CI process then make sure you have finished the CI in 5 minutes flat tutorial before continuing this one.

Implement step definitions to automate your tests

You have setup a CI (Continuous Integration) process when you did the CI in 5 minutes flat tutorial. It is now time to add the newly created scenario to the CI.

The first thing to do is to regenerate the tests to get the descaling scenario exported. This can be done by running the command:


hiptest-publisher -c <path to your config file> --without=actionwords

You should see that a new file has appeared, which name should be based on the folder you created in the previous steps.
Now if you execute the tests, it should normally fail, telling that some action words are missing. Let’s fix that, once again using hiptest-publisher:


hiptest-publisher -c <path to your config file> --show-actionwords-diff

The output you get from this command line vary depending on the way you wrote your scenarios but it should give you a list of changes and the command lines to run to update your action words library.
Normally, you have a command to run looking like this:


hiptest-publisher -c <path to your config file> --show-actionwords-created

This command generate a list of skeletons of functions you have to copy and paste into your action words file. The next step will be to implement them until the tests correctly pass.
You should find a file called “CHEAT SHEET.md” in the same directory as the action words file to help you implement the newly created action words.

Once your action words are correctly implemented, you can safely commit your changes to git. But just before, let’s run a last command with hiptest-publisher:


hiptest-publisher -c <path to your config file> --actionwords-signature

This command will regenerate the actionwords_signature.yml file. It is important to run this command so the next time you (or one of your colleague) run hiptest-publisher with the option “–show-actionwords-diff”, the new action words you have created during this tutorial will not be considered as new ones.

Wrap up

In this section, you have seen how to easily handle changes to the action words library using hiptest-publisher.

Integrate with your CI

Now we have our automated test, we want to make sure it will be executed as part of the CI process. Before pushing your changes to the remote repository, you need to ensure the test will be played in the next build.
To do so, simply add the scenario you have created to the test run named “CI”. You can do this from the scenario (using the menu , then Add to test run) or from the test run itself, using the menu , then Add scenarios.

Once this is done, you should see that a new scenario appears in the menu and a small portion of the pie-chart has gone grey.

It’s time for you to commit the changes you have done and push them into GitHub. As you have already set up the CI in the tutorial “CI in 5 minutes flat”, you have nothing more to do than wait for Travis-CI to do its job (it takes about 10 minutes in worst cases for the job to be started).

A few minutes later, you should see in CucumberStudio that some new results have been pushed to CucumberStudio and the pie-chart corresponding to the test run is now fully green (or partly red, but that would mean there is an error in the implementation of your action words).

Wrap up

Congratulation! You have done all the steps from capturing requirements into a scenario, automating it and integrating with the CI process. Now you have to practice, practice and practice again to become a ninja.

Thanks and please share your feedback. This is gold for us. That would be awesome if you could share this tutorial with your friends and colleagues