DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. So You Say You're Doing BDD — The Story of the Whiteboard and the Nail Gun

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

Learn the fundamentals of behavior-driven development and explore scenarios to see if you're really implementing it.

John Ferguson Smart user avatar by
John Ferguson Smart
·
Nov. 20, 18 · Tutorial
Like (8)
Save
Tweet
Share
13.68K Views

Join the DZone community and get the full member experience.

Join For Free

“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.

agile Cucumber (software) Database Testing

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How To Use Terraform to Provision an AWS EC2 Instance
  • Understanding gRPC Concepts, Use Cases, and Best Practices
  • Spring Cloud: How To Deal With Microservice Configuration (Part 1)
  • What Should You Know About Graph Database’s Scalability?

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: