BDD (Behavior Driven Development)

The BDD (Behavior Driven Development) is an Agile practice created by Dan North in 2003 that aims to create functional tests with a natural language understood by all.

This practice is an extension of the TDD that did not necessarily cover the risks of regression on the chain of functions in order to create a complete path. All unit tests could be “green” while the course could have errors.

This BDD practice encourages the bringing together of technical teams and functional teams; indeed it is an idea similar to the approximation desired by the agile methods.

Principles of BDD (Behavior Driven Development)

Here are the 4 principles of the BDD (Behavior Driven Development) that must be remembered:

1. The participation of non-technical teams in the project
2. Automated scenarios to describe behaviors to make non-regression and to comment on the code
3. Writing the behavior test before writing the associated code
4. Better understand the expected behavior for the technical teams.

Complex implementation of the BDD (Behavior Driven Development)

This practice of the BDD involves many changes in the minds of the company. For this reason, it is much less common in companies than unit tests.

We have seen many IT team try to do this BDD practice in the past; however, they did not capitalize on it. Support is strongly recommended for setting up practices such as this one.

Product Owner not always prepared for BDD (Behavior Driven Development)

Often in agile, we ask the product owners to write themselves the acceptance tests to strengthen the functional quality of the deliverables; sometimes, they’re written by the one who has the testing skills

This BDD practice is sometimes done by developers in some companies; it does not make much sense to impose this work on them. This will probably improve some quality overall but I am not convinced they write all these tests with much desire (and therefore rigor).

I also wrote an article on a type of user-story that requires to write this type of tests (BDD) to the Product Owner: A very effective user-story format: the A4 story.

As a coach, we are seeing more and more of Definition of Done include acceptance tests in the form of functional tests; the agile coaches are certainly there for something because we try to get the teams to constantly look to improve the quality of the delivered products.

However that works for product owners (PO) who have experience in this position but the task can be more complicated for the Product Owner who discover the role. It is essential that the inexperienced POs are accompanied individually by a coach if we do not want the writing of these tests become a point of blockage.

BDD: write a first functional test

BDD: write in Gherkin

We will see how to write a functional test in BDD. For that we will write it in Gherkin language which is the natural language understood by the set of functional test tools.

The language Gherkin is a natural language readable by any person that it is on the business side or on the technical side. This language will describe behaviors without detailing how they are integrated.

The Gherkin language is a language that follows a specific structure where each line and indentation are important (such as python or YAML for technical people passing through here).

Here is a simple example proposed by cucumber (a very popular functional testing tool):

 1: Feature: Some terse yet descriptive text of what is desired
 2:   Textual description of the business value of this feature
 3:   Business rules that govern the scope of the feature
 4:   Any additional information that will make the feature easier to understand
 5: 
 6:   Scenario: Some determinable business situation
 7:     Given some precondition
 8:       And some other precondition
 9:     When some action by the actor
10:       And some other action
11:       And yet another action
12:     Then some testable outcome is achieved
13:       And something else we can check happens too
14: 
15:   Scenario: A different situation
16:       ...

Example of BDD with Cucumber

You will use this syntax to describe your tests. You will describe the feature in whole in the function part and then you will define different possible scenarios.

It is always advisable to purpose scenarios that validate a situation and scenarios that also invalidate this same situation. So, if you meet an error of inversely of a condition in the code, one will detect it immediately (the error is human).

BDD is not an end-to-end test or GUI

Indeed, the BDD (Behavior Driven Development) must imperatively focus on a use case and not on the GUI (Graphical User Interface) or the detail of the infrastructure.

This is an important point because the risk is to end with a set of tests too long to run; this would cause the teams to finally override the tests in case of emergency.

Conclusion BDD (Behavior Driven Development)

Setting up BDD (Behavior Driven Development) is not easy. With a good support on this topic BDD (Behavior Driven Development), you will enjoy these behavior tests to reduce the risk of future regressions in your applications.

To conclude, with this kind of tests and this practice of BDD (Behavior Driven Development), you will significantly reduce the bug rate in the future on the application concerned. A considerable time saving that should not be neglected.

Caution, the training of BDD (Behavior Driven Development) is long! Never force the teams to do the BDD but accompany them.

Reminder: Do not hesitate to send us your feedback on the BDD practice.

• Have your teams easily adopted the BDD?
• Did you give up the BDD? If yes, why ?