At its core, Behavior-Driven Development (BDD) is all about solid communication between and among the parties that are responsible for creating software or web applications. In a typical scenario, the person requesting the product, we’ll call her the Product Owner, has a meeting with the Web Developer and QA and describes what they want the software to do. The Web Developer turns those requirements into a programming language and then it’s tested and implemented. Given that the Product Owner, Web Developer, and QA are all in their own space, speaking their own language, and all expecting the same outcome, what could possibly go wrong? Well, a funny thing happens when a project goes into development—the goals and requirements expressed by the Product Owner are handed over to the development team. This means that in order for the project to continue as expected by the Product Owner, she would have to assume that each development team member translated that conversation exactly as intended. And, like a game of Telephone, that doesn’t always happen.
This is where BDD helps in connecting the dots and closing the gaps. Baked into BDD is an approach where the Product Owner, Web Developer, and QA discuss and solve a particular problem or set of problems together at the start of the project by using specific examples. This ensures that everyone understands the logic behind the intended solution before any line of code is written. In this type of development strategy, the Web Developer builds functionality in small pieces while keeping in mind the intended behavior that is illustrated through examples. BDD has two main components that contribute to its value: 1) it uses ubiquitous language to show examples of how users will interact with the product, and 2), it uses those examples as the basis for testing.
BDD works well for many reasons, including:
– It ensures that each team member has the same understanding of the product and its goals right from the beginning of the project.
– Each team member, even the Product Owner, can actively participate in the development of the product from conception through to implementation.
– Development teams stay connected to the business domain and its evolution.
– The cost of maintenance is reduced as is the project risk.
BDD frameworks aren’t difficult to find and include Cucumber, Concordion, Behat, Jasmine, and others. One of the most popular frameworks is Cucumber which, naturally, is responsible for Gherkin. Gherkin is understood by Cucumber and uses plain-text English (with a little structure, as the company says) which makes it possible for the Product Owner or others in the organization to be involved in development. A .feature describes a single feature or aspect of the system, while each line that isn’t blank has to start with one of the main Gherkin keywords like “Feature,” Scenario,” “Given,” “When,” “Then,” “And,” “But,” “Background,” “Scenario,” and “Outline.”
Example of Gherkin document (Source: https://cucumber.io/docs/reference):
Feature: Refund item
Scenario: Jeff returns a faulty microwave
Given Jeff has bought a microwave for $100
And he has a receipt
When he returns the microwave
Then Jeff should be refunded $100
Now, remember those examples that the team created? Cucumber runs them as automated acceptance tests, and then shows which are working and which aren’t. The result is one document that’s the specification and test for the software. So, you can see that there is a shift from thinking about tests firsts like in Test-Driven Development, to thinking about behavior first. As you are reading this, you may be questioning the very presence of BDD frameworks and processes as a departure from best practices. We should be clear that BDD is simply a re-tooled practice that uses collaboration and a common language as a means to an end.
The beauty of BDD is that the entire web development team, from concept to delivery, is directly involved in the web development process and each team member can test and provide feedback. Granted, there are times when total team involvement may seem cumbersome, but once you get a workable system in place, the process ultimately becomes more efficient. In the end, it’s better to have everyone on the same page, rather than to scrap a project and start again. And, since BDD encourages collaboration, it gives each team member insight into the challenges of each other’s jobs and provides a forum for understanding and learning. In that way, you can look at it as a development strategy disrupter.