Best practices in BDD and how to apply them in software development

Continuing with the development models, we cannot leave out one of the most used methods in terms of technology development focused on behavior, or user response. That's right! BDD is a development strategy that we will specify much more throughout the article. But if you're interested in how smart products work or do exactly what they're told to do, then you need to know about this development strategy. 

The best part? We are not talking about a model that only depends on developers, it also takes into consideration the business model and the real needs that will make the business efficient and profitable. 

Who says that developers work alone and without any guidance? Well, today you will find out more about this in depth. 

What is TDD?

No, you are not reading wrong, you may be confused because we are naming a very different development system right now. But yes, first we will explain what TDD, also known as Test Driver Development, is. 

And what exactly is it and how is it related to BDD? Don't hurry, let's take it one step at a time. Apart from the obvious change of its first acronym, TDD is a development or design model based on testing, as its name suggests. 

So, TDD starts from an idea, and that idea must evolve to a real or functional use by users, but it must go through a series of tests to check its efficiency. Thus, simple evaluation criteria are chosen or criteria that’s easy to apply in a unit test. 

To explain it more easily, you can imagine the following sequence of tests: 

1. Write a unit test (that fails), to identify the reasons and develop possible solutions. 

2. Write the necessary code so that the unit test can pass the test and stop failing. 

3. Refactor or optimize the code. This is to eliminate redundancies and improve the code without changing the behavior so that it can be functional. 

Now, this method consists of repeating over and over again, adding different unit tests, and repeating the cycle one by one until it is determined that the required product is complete and will meet the customer's needs. 

It is worth mentioning that TDD is a type of test-driven development that is specially designed for developers or programmers. That is to say, here not the whole team is involved, as it can happen with the BDD that involves developers, clients, and work teams to build a specific application or product. 

TDD, then, is a test of unitary methods to build software that meets certain conditions of use. 

What is BDD? 

BDD, on the other hand, is defined as a behavior-driven development strategy. And, in simple terms, it would be the natural evolution of TDD, although without including testing parameters, which is its most outstanding difference. 

In this opportunity, the objective is to fulfill certain scenarios and to see how the application or object would respond to those scenarios to meet certain user needs. It’s for this reason that this strategy is considered a common language among developers and non-technical work teams. 

What is sought, is to improve communication between the two to create a much more efficient product according to the market in question. While BDD testing focuses on the behavior of the user who employs or uses the application or product, TDD focuses on the behavioral functions of the same. 

Look at it this way: 

• TDD: seeks to fulfill only the operation of the code or functions of the software. 

• BDD: seeks to fulfill the business by performing behaviors under certain possible scenarios. 

Do you want to learn BDD or TDD?

Making the distinction that we’ve raised, it’s possible that you ask yourself, then, what should I really learn? Well, if you want to become a good software developer, it will be necessary for you to understand and apply both methods or strategies. 

Why is that? Simple, because these methodologies and strategies are not mutually exclusive. 

That is to say, just because you work with one,  doesn’t mean you will not be able to work with the other. In fact, it’s quite the opposite. It’s advisable that you make use of both methods to be able to cover a wider range of operations and that our software is of the best possible quality. 

TDD will give you a very high code quality which will make the software very stable and efficient, while DBD will give you a much more competent system behavior.

Differences and similarities between TDD and BDD 

In order to make it  the characteristics that differentiate each model much clearer to you, we will expose them through a simple identification list: 

TDD

• It’s dedicated to or can only involve developers, who know the testing method for the software being developed. 

• It’s a method that only focuses on the operation of the code, that is, that the software as such does not have any type of error and can be executed correctly. 

• It’s focused on a low level of testing, that is to say, it specializes in the operation of the software and in making sure it doesn’t produce system failures. 

• The purpose is to build a functional application, product, object, or software. 

BDD

• It’s not only focused on developers but involves the entire team, ranging from programmers to business professionals. 

• The focus is on the behavior of the software with respect to the users who will make use of it. That is, how we want the product to work taking into account the different possible scenarios. 

• The tests that are performed are considered high-level, since they offer coverage of what can happen in different situations that affect the users in question.

• The purpose of this development is to build or design the right things for each scenario.

Similarities 

• Each of the developments is based on a test that can support the operation, usefulness, and effectiveness of the software in question. In other words, the software is first subjected to different tests, both functional and behavioral, before being put to its intended use. 

• Both methods or strategies focus on an automatic testing process, that is to say, it’s possible that the software itself is capable of executing its functions automatically through direct order. 

How to apply BDD in software development? 

To apply this development strategy, it’s necessary to implement a programming language in which both developers and business professionals, who could well be the customers you would work for, can understand each other. 

There is a very interesting programming and design language that can work perfectly for this type of joint and collaborative project. It’s called Gherkin and it’s a kind of common language for users with and without technical knowledge of software development.

Applying BDD in Gherkin will be possible thanks to 5 elements that you will have to take into account so that the development is carried out successfully and meets the client's expectations. For example: 

1. Feature

This is the name of the functionality to be tested. That is the behavior of the software in a possible scenario. The name must be clear and as explicit as possible, which in turn will have a brief description of what you want to develop. 

Exemplifying, it would be as follows: 

Playing the role of "include role", I want the software to perform "features or function", and thus be able to "mention the benefits". 

Once you have the description established with the work team, you will use it to build different possible scenarios according to that specific behavior.

2. Scenario 

It’s the description of a possible situation based on the established behavior expected from the software in question. That is to say, it indicates what is going to be tested, and for this, you must comply with the following steps or sentences...

3. Given 

This is the statement that provides the context of the scenario in which the corresponding test will be applied. It gives you all the information corresponding to the requirements and necessary steps for the software system to be in the state in which you want to perform the test. 

In short, they are the necessary prerequisites that must be present for the test scenario. 

4. When

These are the actions that must occur to start the test or behavioral test. It’s the interaction that the user will have with the system and the function that the user wants it to perform. 

5. Then

It’s what is expected from the tests, or the possible expected results of the test to be performed, the possible changes of the system are observed and it’s evaluated if these changes are what is really being looked for in the software. 

A practical example of BDD with Gherkin

Once you know the steps of application of a BDD through the Gherkin language, the following thing is to put it in practice. So we present a scenario in which you can apply this language as a whole, and that will give you a much clearer idea to be able to develop it. 

• Featured: cash withdrawal at a bank automatic teller machine 

As a user or customer of bank "x", I want to be able to withdraw my money in cash to be able to pay for products and services directly. 

• Scenario: being able to withdraw $20, $50 and $100 in cash at the user's choice. 

• Given: in case the ATM is still in operation. 

• - And: has sufficient cash. 

• - And: can effectively process each option. 

• When: when the user selects the cash withdrawal option. 

• - And: choose any available option. 

• Then: the cashier will withdraw the selected amount of cash to the user. 

• - And: will deliver the cash to the withdrawal grid. 

• - And: the consolidated position or available fund of the user's account will be updated. 

• And: the amount of cash available in the cashier will be updated.

As you can see, the specific behavior of ATMs in banks is being tested. This is the reason why we are dealing with a Bdd case and it’s being carried out by means of the Gherkin language. 

The title or function to be tested in the feature was established. At the same time, a brief description is provided identifying the type of user, what the user wants to obtain, and the benefit he/she expects to obtain from said function. 

Thus, a possible scenario is established. Remember that there can be multiple scenarios and all of them must go through a behavioral testing process. 

Once the scenario is established, the context of the situation is established, then the "when", which identifies the user's action and what would happen when the user performs that action. 

As you can see, it is a fairly simple type of language to understand, both for developers and non-technical people, and for that reason, it is a common language that can be understood and established together. 

 The Bdd is a very interesting and popular strategy due to all the possibilities it offers to both developers and the company in question; they are able to create software together that can meet all possible needs through different possible scenarios. 

Once you have a much better understanding of what this behavioral development strategy consists of, we invite you to take on a small challenge. It consists of testing your understanding of the topic, so the test will consist of the following: 

 Create a possible Bdd situation or scenario and develop it by means of Gherkin language through the comment box. 

We would love to read you and clarify as many doubts as possible.