So You Say You're Doing BDD — The Story of the Whiteboard and the Nail Gun

“BDD is what makes you BE agile, instead of just doing agile.”

It isn’t hard to find a team that says they are doing Behavior-Driven Development, or BDD. This isn’t too surprising, since, when done well, it is an extremely effective way of delivering high-value, high-quality solutions to your users. Unfortunately, the number of teams practicing BDD effectively, and getting the full benefits, is fewer.

There are plenty of people writing tutorials about how to do “BDD with Cucumber and Selenium;” so many, in fact, that it would be easy to believe that Cucumber is an automation tool for web testing. Some of them even give a passing mention to the collaborative nature of BDD, before they plunge into poorly-written Gherkin scenarios. But only a few sources explain what BDD is actually about, or give realistic examples of what a good Cucumber scenario might look like. For someone not familiar with the field, it is understandably hard to sift the wheat from the chaff.

What Is Behavior-Driven Development?

Behavior-Driven Development is a collaborative practice where teams use structured conversations about examples of business rules to build up a shared understanding of the business problems that need to be solved. The team can formalize these rules in the form of “executable specifications,” which can be automated to provide fast feedback about progress during the work, and living documentation and automated regression tests once the feature is delivered.

Asking “How do I do BDD with Cucumber?” is a bit like asking “How can I build my house roof with whiteboards and a nail gun?” You are asking the wrong question. BDD is a collaborative requirement discovery process. Cucumber is one of many tools that can be used to write executable specifications and living documentation that emerge from this discovery process. Selenium is one of many tools that can be used to automate these executable specifications. 

Many teams start with the assumption that Cucumber scenarios should be UI tests written using Selenium. Implementing Selenium test automation scripts in Cucumber is like like building your roof by nailing whiteboards to a wooden frame – it might kind of work, but there are better ways. But when a team practices BDD well, the scenarios read much more like business-readable user requirements than test scripts, which makes them both more useful and easier to maintain.

Show Me Your Scenarios, I’ll Tell You If You Are Practicing BDD

Let’s look at some examples of what I mean. 

Manual Test Scripts Are Not BDD Scenarios

Imagine you are working on a new website for beekeepers. The site sells online training for various beekeeping activities. To stay on the good side of the law, the company needs to collect the right amount of sales tax. And the sales tax rules vary quite a bit from country to country.

One of the feature files looks like this:

Feature: Buying online courses

  Scenario: Buying an online course
    Given the user opens the browser
    And the user enters 'Beehive Building' in the search field
    And the user clicks on search
    Then the user should see the 'Building Beehives' course
    When the user clicks on 'Beehive Building'
    And the user clicks in 'Add to Basket'
    And the user clicks on 'Proceed to checkout'
    Then verify that 'Building Beehives' course appears in the order summary
    And verify that the sales tax is correct 

This scenario feels like a series of instructions for a manual tester. Unfortunately, the most important thing – checking the sales tax calculation – is left a bit vague. What exactly are we checking?

The scenario is also very UI-centric. It assumes we will be automating the scenario using Selenium WebDriver. But is this really necessary? There are a lot of different sales tax rates around the world – do we really need a UI test to verify each of them?

Discover Scenarios, Don’t Write Scripts

The scenarios that come out of BDD discovery sessions rarely look like this. In a BDD discovery session, you might use Feature Mapping to understand the overall flow.

Or you might use example mapping to explore edge cases and variations. Or you might just sketch out a table on a whiteboard. In all cases, the conversations aim to explore business rules and constraints, rather than writing test scripts. 

Later on, a tester and BA might pair up to formalize this requirement into a scenario that goes something like this:

Feature: Calculating sales tax

  Sales tax needs to be applied to online purchases, according to local regulations

  Scenario: Applying EU sales tax
    EU Sales tax for online services is calculated based on the buyer's home state

    Given Francis lives in France
    And he has added the 'Beehive Building' course to his basket
    When he proceeds to the checkout
    Then the order summary should contain the following:
    | Course           | Price  | Tax Rate | Sales Tax | Total  |
    | Beehive Building | €30.00 | 20%      | €6.00     | €36.00 |

The QA might propose another scenario that lists the VAT rates for each country:

Feature: EU tax rates

  Scenario Outline: EU sales tax rates depend on the country

    Given Francis lives in <country>
    When he makes an online purchase
    Then the sales tax should be <rate>
    Examples:
    | country | rate |
    | Austria | 20%  |
    | Belgium | 21%  |
    | Croatia | 25%  |
    ...

This second case is an example of a more detailed scenario. Detailed scenarios like this are not usually discussed exhaustively during discovery sessions. But they can be helpful in more rigorous or regulated environments, where users and stakeholders like to see evidence that business rules have been implemented correctly and completely.

Notice how these scenarios describe the VAT calculation logic, but without committing to a particular UI implementation. In fact, it could even be automated without using the user interface at all. 

Conclusion

There is much more to BDD than Cucumber and Gherkin. In summary, the teams that do BDD well are rarer, but they are inevitably high performing. They work in tight collaboration with their product owner, or even with the end users. They work with the product owner or end users to write specifications in clean, clear business language, that they then transform into executable specifications using tools like Cucumber and Serenity BDD. They don’t write Gherkin directly with the users (this would be boring and unproductive), but they collaborate with them using facilitation techniques such as example or feature mapping, or simply by drawing tables on a whiteboard.

If you would like to understand more about the BDD process and more effective ways to automate your acceptance criteria, take a look at the Serenity Dojo courses. There is a free Introduction to BDD with Cucumber and Serenity BDD course, which covers a lot of basic BDD principles, as well as a lot of other material on BDD and test automation topics to explore.