Behavior Driven Development

BDD (Behavior Driven Development), is a behavior-directed development strategy which has evolved from TDD (Test Driven Development), although it is not a testing technique.

Unlike TDD, BDD is defined in a common language among all stakeholders, which improves communication between technological and non-technical teams. In both TDD and BDD, tests must be defined before development, although in BDD, tests are focused on the user and system behavior</b>, unlike TDD that focuses on functionality.

BDD Features

The main advantage is that all BDD definitions are written in a common language. The main objective is for the team to describe the details of how the application to be developed should behave, and in this way it will be understandable by all.

Unlike BDD, TDD works properly as long as the organization’s management is familiar with these unit tests, ultimately their technical skills are strong enough, and this is not always the case.

In these circumstances, BDD has the advantage that unit tests can be written in a common language used by all interested parties. This access to clearer communication with minimal technological jargon is probably the greatest advantage of using BDD, which makes it possible for collaboration between technical and non-technical teams to be executed more efficiently.

What should I keep in mind before implementing BDD?

• Each requirements must be converted into user stories, defining concrete examples.
• Each example must be a scenario of a user on the system.
• Be aware of the need to define "specification of user behavior" rather than "unit test of a class".
• Understand the 'Given-When-Then' formula or others such as 'Role-Feature-Reason' user stories.

'Given-When-Then'

To define the BDD cases for a user story, they must be defined under the ‘Given-When-Then’ pattern, which is defined as:

• Given ‘given’: The scenario is specified, the preconditions.
• When 'when': The conditions of the actions to be executed.
• Then ‘then’: The expected result, the validations to be performed.

A practical example would be:

• Given: Since the user has not entered any data in the form.
• When: When you click the Submit button.
• Then: The appropriate validation messages should be displayed.

Advantages of BDD

• You are no longer defining 'tests', you are defining 'behaviors'.
• Improves communication between developers, testers, users and management.
• Because BDD is specified using a simplified and common language, the learning curve is much shorter than TDD.
• As it is not technical in nature, it can reach a wider audience.
• The definition approach helps common acceptance of functionality prior to development.
• This strategy fits well with agile methodologies, as they specify requirements such as user and acceptance stories.