Behavior Driven Development, or simple BDD, is modern approach in applying knowledge about software behavior. BDD bridges the communication gap between different stakeholders gathered arround software requirements. This is achieved using language form that is understandable by the business and in the same moment detail enough to be considered a specification (known as: Business Readable DSL)
In agile approaches, business requirements are expressed in form of epics and user stories. Together with user stories, some sort of acceptance criteria is defined that will be used later on to assure proper system behavior. Agile approach that applies BDD places scenarios as acceptance criteria. Scenarios are written in DSL and come as the first refinement of user stories that includes the technical aspect of the requirement and in the same moment hides technical details. With that level of abstraction, developers are still able to implement actual steps and make them executable, meaning that we actually have executable, “human-readable” specification.
To demonstrate this on real-world case and check how it all looks, let’s increase business value of our cool ticket service. Ticket service should have option that will allow customers to purchase ticket:
As a Customer, I want to be able to purchase ticket, so that I can travel to my destination
Business has surprisingly decided to allow customers to purchase tickets. Discount period can be granted depending on the company policy. To be more precise, we can define expected behavior with the following scenarios:
Feature: Ticket purchase Scenario: Ticket purchase with discount for regular customers Given tickets can be purchased When regular customer makes request to purchase the ticket And request is within the acceptable discount period defined by the policy Then price of the ticket should be reduced for amount defined by the policy And payment transaction should be initiated with payment provider And customer should be "notified" about the purchase Scenario: Ticket purchase without discount for regular customers Given tickets can be purchased When regular customer makes request to purchase the ticket And discount period defined by the policy has expired Then ticket should have regular price And payment transaction should be initiated with payment provider And customer should be "notified" about the purchase
Similar, we could define scenarios for the premium customers.
BDD scenarios can be our complete acceptance criteria. As they are written in special DSL, we can make them executable and include in continuous intergation process. Gherkin is the language specially designed for expressing behavior. Gherkin comes with many features that can be used to achieve precise expressions. Here is one of the excellent guides.
Having scenarios defined like this can have huge positive impact on project during all stages. Description of the exact business situations can be really helpful for new team members on existing projects. There are known situations when business rules and expected behavior can be figured out only from code. In such situations, creating and asserting scenarios with the business can be a big step forward in understanding unknown software systems, existing and new.