How I Benefit from Behavior-Driven Development

This article shares my experience practicing Behavior-Driven Development and how each role can benefit from it.

What is Behavior-Driven Development (BDD)?

BDD is a software development process that emerged from Test-Driven Development (TDD). Some practitioners say that BDD is in fact done TDD correctly.

BDD focuses on the behavior of an application and asks questions before and during development; therefore, it is less likely to have miscommunications among stakeholders. The goal of BDD requirements, referred to as User Stories, is to not only build the thing right, but also to build the right thing.

Software Development Process

Common software development workflow could be like this:

1. Clients ask for a new application, and business analysts gather requirements from them.
2. Developers estimate the work and implement the application based on the requirements provided by business analysts.
3. Quality assurance engineers test the application implemented by developers.
4. Clients perform user acceptance tests.

Difficulties Each Role Might Encounter

During the software development processes, each role in a project will encounter different challenges:

1. Clients
   • Describe all their needs and validate the requirements gathered by business analysts.
   • Come up with scenarios for user acceptance tests.
2. Business Analysts
   • Design the software (UI, UX) and cover all clients’ needs.
   • Convey the requirements to developers.
3. Developers
   • Understand the requirements provided by business analysts and come up with estimates.
4. Quality Assurance Engineers
   • Come up with scenarios that can test the software as thoroughly as possible.

Ubiquitous Language and Behavior-Driven Development in Cucumber

Based on my experience, software projects can suffer from low-quality communication among stakeholders, especially between non-technical clients, domain experts, and programmers on the team. To resolve communication difficulties, an easy-to-read, written ubiquitous language can be extremely helpful. Ubiquitous language is the term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users, and it applies equally well in BDD.

The following are how each role in the team can practice BDD in Cucumber and utilize the Cucumber features written in a ubiquitous language for a project:

• Business analysts gather software requirements (aka user stories) focusing on the behavior of the system and write Cucumber features in Gherkin.
• Since Cucumber features written in Gherkin are easy to understand as plain English, clients can read and validate them and can use them for user acceptance tests. Moreover, Cucumber features become documentation and user guide for the software.
• Developers can estimate the work more accurately based on each Cucumber feature. In addition, the Cucumber features become automated integration tests; the goal for developers is then to pass these Cucumber tests.
• Quality assurance engineers can view Cucumber features as blueprint to test the software.
• All stakeholders can collaborate more closely by producing concrete examples together using the same language like Gherkin.

Case Study

So, let’s take a look at one of my projects and see how stakeholders benefit from behavior-driven development in Cucumber.

Client asks for this:

“Hey, we want the system to tell our users if the books they want to check out are ready for picking up. In addition, sometimes librarians accidentally update book barcodes in the system while those books are still on the shelves, and therefore we can’t find the locations of those books with the new barcodes. Can we have a feature to prevent that from happening again?”

Business analysts then come up with the following Cucumber features and scenarios (note that they focus on the behavior changes of the application):

Feature: Check out books from shelves
  As a user
  I want to submit an order of books that I want to check out
  So that the system can tell me if those books are ready for me to pick up
 
  Scenario: Submit an order of books with book status IN and ready to pick up
    Given I am logged in
    And 2 books with book status IN are in my order
    And I am on my order page
    When I press 'Submit Order'
    Then I should see 'Order was submitted successfully'

Feature: Prevent librarians from updating book barcodes with book status IN
  As a librarian
  I want the system to prevent me from updating book barcodes while the books are on the shelves
  So that people can find books on shelves with barcodes in the system
 
  Background:
    Given I am logged in
    And book ID 1234 has the barcode 'BH710002'
 
  Scenario: Try to update the barcode of a book with status IN and failed
    Given the book status is IN
    When I go to Updating Book Barcodes page
    And I attach the csv file 'batch_upload_book_barcodes_1.csv'
    And I press 'Upload'
    Then I should see 'ID 1234'
    But I should not see any checkbox for the book
 
  Scenario: Try to update the barcode of a book with status OUT
    Given the book status is OUT
    When I go to Updating Book Barcodes page
    And I attach the csv file 'batch_upload_book_barcodes_1.csv'
    And I press 'Upload'
    Then I should see 'ID 1234'
    And I should see a checkbox for the book

Clients might want to discuss more details with business analysts and update the Cucumber features above in order to cover their all their needs. They as well follow those scenarios to perform user acceptance tests when developers finish the feature modifications.

Developers have well written Cucumber tests provided by business analysts. They might want to update the Cucumber tests for any reason, but business analysts and clients can easily validate them since they are written in Gherkin. After the updated Cucumber tests are validated, developers’ goal is to pass the tests. Since these tests focus on behaviors and written before implementation, this is Behavior-Driven Development.

Summary

Behavior-Driven Development (BDD) specifies that tests of any unit of software should be specified in terms of the desired behavior of requirements.

Software teams and stakeholders can benefit from using ubiquitous language written in Gherkin and a BDD tool like Cucumber to minimize communication difficulties and merge specification, automated integration tests, and documentation into one.

This is an update to the post originally published in October 2016.

Next Steps

If you’re looking to work with a team focused on behavior-driven development, Soliant Consulting may be a good fit for your project. Contact us today to discuss your needs and goals.