BDD: Tasks and Activities

It's a beautiful Monday, and your project leader, after spending a weekend at a software quality conference, comes to you with an important task. After attending a talk on BDD and being thrilled by it, he now wants you to include Behavior Driven Development practices in the company's projects.

You understand the great benefits of BDD, but how do you accommodate it in an agile process with tests, modular deliveries, etc.?

Well, you find yourself in a big predicament. But nothing that a software engineer isn't used to. As a first measure, you try to find some material on the subject on the internet. You end up finding excellent books on the subject (https://bddbooks.com/index.html) and you come across a list of activities related to BDD. A simplified version is illustrated in the figure below.

The big question is that BDD can fit into virtually any software development process. In this example, we can see how, from a user story, we can get to the software coding. If unit tests are used, nothing changes! We just start writing the tests as soon as the scenarios are automated.

Well, let's move on to the activities involved:

Discovery: a set of practices that uses concrete examples to break down the ambiguities present in the requirements. The main result of this activity is a shared understanding of the use cases.

Formulation: in this activity, the examples discussed in the Discovery phase are transformed into Scenarios following a standardization and business-oriented language. Generally, the examples are written using the Gherkin language (https://cucumber.io/docs/gherkin/reference/).

Automation: in this phase, automated tests are written for each of the formulated examples (in Gherkin). This way, we can check if the user stories are still valid after some changes at the code.

According to these activities, we will move from our traditional use cases (you know? that dead documents!) to testable examples, using a language completely understandable by the client.