BDD: from the best practices to its drifts

Written by Gilles Ménède | Jan 30, 2024 5:00:00 AM

BDD (Behaviour Driven Development) is a practice popularized by Dan North in 2003, and derived from TDD (Test Driven Development), to which it is complementary.

Why use BDD? Precisely to address the common problems with specifications in Agile mode:

No formal explanation of the context,
Specifications that can be interpreted differently by different profiles or actors,
Not necessarily up to date.

BDD is therefore an Agile practice aimed at synchronizing the various players developing a feature with what it is supposed to do. The aim of BDD is to design acceptance tests, illustrating the functionality’s behavior, using methods such as the 3 amigos or example mapping. The BDD approach is generally carried out in 3 stages: discovery, formulation and automation.

The right application

The players are synchronized using co-designed examples that illustrate the functionality’s behavior: this is the discovery of the US, often achieved thanks to the meeting of the 3 amigos (customer, developer and tester profiles), which provides a common understanding of the need, and enables acceptance scenarios to be written to validate the acceptance criteria.

These examples are formulated using a common language, Gherkin, easily understood by the different profiles of the 3 amigos. This Gherkin language is formatted to write structured tests in a natural language, and a priori understandable by all. Gherkin tests are written with the 4 basic elements: GIVEN / WHEN / THEN … AND (GIVEN a certain context, WHEN I perform an action, THEN I have a result1 AND a result2).

From this structured (and formatted) formulation of the functionality’s behavior, it is possible to integrate these examples into a software tool, like Cucumber for example, which will interpret this Gherkin language to run automated acceptance tests, adapted to these examples. This is the automation stage.

Its drifts

BDD is now used in many companies to test the behavior of certain functionalities in close collaboration with users. But even if BDD is used to achieve a common understanding of needs, there are still a number of confusions surrounding this Agile practice, which can lead to certain abuses. What are they?

BDD is seen solely as automation

In this case, we lose the essential contribution of BDD: the ability for everyone to have the same understanding of what’s expected.

Scenarios are written and designed solely by the PO or tester.

In this case, examples do exist. Unfortunately, their quality is often insufficient, as they have not been examined by different profiles.

Failure to write acceptance scenarios

Sometimes, synchronization meetings are held, but in the end, no scenario emerges. This is problematic in the sense that much of the information is lost because it is forgotten. It also forces more people to attend these meetings, which requires a greater investment.

Tests not comprehensible to all profiles

A BDD test must be understood by everyone on the team (and sometimes beyond). Writing tests that are not understood by everyone does not ensure that everyone understands the same thing. In general, it also doesn’t allow the business to really validate what will be developed.

The BDD is created during the sprint

During a sprint does not mean during development. But even when BDD is performed before development, this process has an impact on the team, which has had to commit to delivering a US that it may not have fully understood.

Using Gherkin as BDD

Gherkin is a language. BDD can take other forms… just as it is possible to run tests in Gherkin that are not BDD (e.g.: the Karaté tool offers tests in Gherkin that cannot be understood by functional profiles).

Before the sprint, the BDD practice consists, through discovery, in validating a common understanding of the requirement by all the players involved. This understanding is formulated through examples, acceptance criteria and acceptance scenarios, which are then implemented in a tool for the design and execution of automated tests.

Applying the various stages of this approach will help to combat BDD drift and, above all, the confusion currently encountered over the various terms surrounding the BDD concept.

View full post