Behavior-driven development (BDD) allows the so-called three amigos to collaborate together in the process of software development. The three amigos are development teams, who build the nitty-gritty details, QA teams, who are experts on how and why things break, and product owners, who represent the high-level goals of the business.

With BDD, the plain English product specifications that define what the development team must build are themselves executable. This means that QA teams and product owners can contribute to the automated testing process, while the developers need to implement the details for the automated testing steps laid out in the specifications.

Why BDD?

The easiest way to explain why BDD is beneficial is to look at two automated tests that attempt to do the same thing, one using traditional automated tests, and the other using BDD.

First, we have a Ruby on Rails Spec that goes through the process of defining a user as prospective buyer, navigating to the tesla.com website, and then walking through the various steps to configure a Tesla Model S and check that the price is accurate:

And here is the same automated test, but this time using the Gherkin syntax, which is used for BDD:

Comparing these two, it’s easy to see why behavior-driven development has become popular. It makes it easy for anyone to look at the specification, understand them, and make adjustments or add new scenarios without having to be a software developer.

Another benefit is that the resulting BDD scenarios can easily be executed manually to validate the system is working correctly, in addition to being turned into automated tests by implementing the defined steps in code, such as what the automated test should do to implement, “Enhanced Autopilot is ‘Selected’”. The flexibility to seamlessly move back and forth between manual and automated test execution is not really available with either traditional manual or traditional automated tests.

Gherkin

Gherkin is the syntax used to define BDD tests (the name comes from the initial BDD testing tool called Cucumber). You can find a reference for it here, but we’ll go over the basics.

Gherkin stories are written with a few simple keywords, primarily Given, When, Then, And, and But.

• Given steps are used to describe the initial context of the system - the “scene” of the scenario. It is typically something that happened in the past.
• When steps are used to describe an event, or an action. This can be a person interacting with the system, or it can be an event triggered by another system.
• Then steps are used to describe an expected outcome, or result.
• And and But steps are used to extend a Given, When, or Then step, so instead of writing multiple Given steps, you could write Given .. And … And

So what exactly does a more complete Gherkin specification look like?  Let’s look at some bank transactions with BDD tests:

In the above example, we have a straightforward set of positive and negative scenarios that lay out the transactions for an ATM. If these scenarios are used in an automated test suite, the developers simply need to fill in the code for how the steps should function.

What’s Next?

In the next part of this “BDD FTW!” blog series, we’ll go into more detail about the other keywords you may have noticed in these Gherkin examples: Feature, Background, Scenario, and some others. Then, I’ll expand into how we’re using BDD here at Hexawise, and I’ll go into some more detail about Hexawise Automate, our product designed to turn your Hexawise test plans into BDD tests. Hexawise Automate expedites the process of writing your data-driven BDD scenarios so that you can do more with less time and effort.

Blog Cover Photo by Natalie Rhea Riggs

Related: Automating Gherkin Tests with Hexawise - Using Hexawise to Export Values for Gherkin (Given, When --> Then) - How a Book Club Impacted Our Software Development Practices at Hexawise