From the course: Cucumber Essential Training

Basic concepts: BDD

From the course: Cucumber Essential Training

Start my 1-month free trial

Basic concepts: BDD

“

- What is BDD, or Behavior Driven Development? BDD is a technique for collaboratively defining software behavior with the help of concrete examples. It facilitates software testing because it focuses on testing software behavior from the perspective of well-understood and well-defined software features written in business language. BDD focuses on concrete examples or well-defined business rules or scenarios. We will review an example of a concrete example shortly. BDD is also a test-first approach just like test-driven development, where you implement a system feature after the test case for that feature is already written. If you're not familiar with TDD, or concrete examples, no worries, we will discuss these topics in this lesson. But let's first discuss a few traditional requirement analysis techniques that pre-date BDD. One, software requirement specifications. In this approach, we define requirements in a system shall do something, user will do something style. The second approach is to use use cases, which is a set of user-system interactions to produce something of business value. The third approach is to use a user story, where we write specifications from the perspective of a user role. As an example, as a restaurant manager, I should be able to overwrite a bill amount. These techniques are useful and applicable in many cases, but, one key problem with this approach is that specifications are written in a way that makes it open to interpretations. The requirement, system shall calculate interest, can be interpreted in different ways by different categories of stakeholders. Testers, developers, and business analysts. You can, of course, make things better by defining requirements more explicitly, but that requires extra effort. Let's see a concrete example. For a bookstore website, a cancel order feature is being discussed. This feature could be expressed as given I am logged into the website, when I cancel an order, I should see an order cancellation confirmation message and a refund should be processed. Now imagine if this feature was being discussed that would also create some questions like, can I cancel an order that is already shipped? Is there a cancellation fee? Can I cancel an order without logging in if I know my order ID? All these conversations would refine the feature and, perhaps, split the feature into multiple scenarios. This information would be captured in a pre-conditioned action outcome style and that would be the ultimate source of truth for the three groups of stakeholders, business, implementation, and testing. We just defined BDD. Before we proceed further, let's briefly discuss what is Test-Driven Development. In test driven development, you write a test case, then you write code to fix compilation errors so your test case would compile the new implement code to satisfy the test case. You continue to refactor and repeat this process until you have your system implemented. This test-first approach is also used by BDD. Let's wrap up this lesson with a discussion on the three key aspects of BDD. Are you working collaboratively? It's very important that different categories of stakeholders, business, implementation, and testing are working together. Are you defining software features as concrete examples? These concrete examples are captured in software feature files, which is what all stakeholders will refer to to verify if the system meets business goals. And finally, are you driving your implementation from feature specifications, or are you using test-first development?

Contents