Using BDD in DevOps environments

What is BDD?

The name speaks for itself: es behaviour-driven development is development guided by the expected behaviour of an application. As with TDD, which is really more a design technique than a testing technique, BDD is a tool for defining requirements and functionality that results in the automation of acceptance testing. You might also hear it referred to as Acceptance Test-Driven Development (ATDD) or Specification by Example.

BDD has several key advantages:

• It’s a highly collaborative tool that allows the business, development and QA to work together and better understand what we’re developing, so that we build the right product according to agreed specifications.
• It provides a framework for automating acceptance testing, which is fundamental to implementing continuous delivery because of the high level of reliability this provides.
• It provides early feedback for both the business and development. There’s no need to wait until a delivery is complete before testing; it can be tested continuously, providing us with continuous feedback.

BDD fulfils two fundamental principles in software development:

• Build the correct product.
• Build the product correctly.

Use of a Common Language

BDD is based on the use of a neutral language understood by all those involved: the business, development and QA. This language can also be interpreted by machines, which means that we end up with executable specifications and up-to-date documentation.

The most commonly used language is Gherkin. Using just a few keywords (Given – When – Then), Gherkin can describe the behaviour of an application through scenarios. I’m not going to provide a detailed description of Gherkin in this post, but I do want to show how it’s a fundamental part of BDD. In my opinion, writing scenarios that are both correct and appropriate is key to the success of this strategy.

Let’s look at an example to illustrate how Gherkin works:

The example above describes the scenario for withdrawing cash. It’s a very simple example but clearly illustrates how to break down the desired behaviour. The goal is to explain functionality as a set of scenarios that describe this functionality.

A Meeting of Three Friends

If preparing these scenarios is so important, who should write them and when? The answer to this question is the “meeting of three friends”. This meeting involves the Business, Developers and Testers. Through discussions and examples, they jointly write the scenarios that describe how the functionality being developed behaves.

The outcome of this meeting is a shared understanding of the functionality by all those involved, along with a series of scenarios written in Gherkin. This meeting happens at the very start of development for each piece of functionality. And inside the Sprint if you’re using Scrum.

Application Development and Scenario Automation

To write effective automation tests, we need to keep in mind that we’re working across several layers that need to be clearly separated:

• Business layer.
• Layer describing the business process.
• Technical layer.

The stability, clarity and rate of change of each layer are shown in the figure below:

Developers and testers work in the technical and process layers while business teams work in the top layer.

Using appropriate programming design patterns, such as pageObject or Screen Play, should ensure we’re working in the right layer. These good programming practices are particularly important when developing user interface tests.

Definition of Done

In agile frameworks, the Definition of Done (DoD) is an extremely useful concept. It tells us when a particular piece of functionality can be considered complete and establishes common, mutually agreed criteria to support this.

One advantage of using a Cucumber-like library is that, when running it over the described scenarios, it creates a report indicating how many features, scenarios, steps, etc. we’ve implemented and how many we still need to implement.

Based on this report, we can clearly see when a certain piece of functionality has been completed: it is done when all scenarios have been automated and all tests have passed.

If you’re using Scrum, all definition, development and automation work occurs inside the Sprint. Therefore, a story will only be accepted when it meets the agreed Definition of Done.

Integration into the Deployment Pipeline

Once we’ve written the tests, we can run them as part of our deployment pipeline and use them to validate a given version of our application. The aim is to provide feedback and assurances on what we’re planning to deploy to production, confirming that everything successfully passes all the acceptance tests we’ve developed. This integration into the pipeline ensures transparency for everyone involved in the development process, including the business, QA and development teams.