A few benefits you get by doing BDD

Behavior Driven Development is a great way to avoid a common situation we find in the process of software development between teams. Very often, the developers and the business professionals are unsatisfied due to the fact that a lot of overwork is done and that many times, time & resources are wasted.

In general, the common problem we find is a lack of communication between both sides, implying that developers don’t misunderstand what is needed by the business itself and the business professionals misunderstand what the developers are really capable of.

In this article I would like to get a deeper understanding of what is Behavior Driven Development, its difference with TDD, a few tools to use and great benefits you get.

 

What is Behavior Driven Development?

 

Behavior driven development, or BDD, is another agile software development process that encourages collaboration in a software project between developers, QA, project managers and the business team.

It was invented in 2003 by Dan North as a response to test-driven development (TDD). On the “Agile specifications, BDD and Testing eXchange” in November 2009 in London, Dan North gave the following definition of BDD, which I actually really liked:

“BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”

It enables the technical team and the business team to reach their end goals. In fact, it helps when it comes to defining the desired business outcomes, to communicating what needs to be built by the developer and to understanding what are the technical challenges they might encounter.  

Basically, with BDD you focus on getting a clear understanding of the software behavior you are aiming for, by communicating with stakeholders. So developers keep their focus on why a code should be created instead of putting too much emphasis on technical details.

Now that we know a bit more about BDD, let’s see what are the main differences with TDD.

 

How is BDD different from TDD?

 

Many think that BDD and TDD are the same and many are confused about what is what. When we talk about TDD, we talk about a set process. You are basically using automated unit tests in order to give the developers a direction on how to design the software. BDD can be seen as a set of best practices for writing great tests.

I would say that the biggest difference is that Behavior Driven Development you write test cases in a natural language that non-programmers are able to read. To express the purpose of a code, the developers combine their native language with the ubiquitous language of DDD (Domain Driven Design).

Instead of coding the functions, you tell the code exactly what you want it to do, by using a style that is closer to our way of writing a sentences. You get a clearer understanding of what the system should do from the perspective of the developer and the customer while TDD only gives the developer an understanding of what the system should do.

That means that BDD enables the developers and the customers to work together on the requirements analysis that is contained within the source code of the system. Therefore BDD becomes quite helpful when it comes to communicating with all the members of a cross-functional product team.

Instead of having tests that are only helpful for engineers, you have a test that helps all. It improves the collaboration between the parties and enables developers to get a clearer scope of the features that are required and the customer get a better idea of what will be delivered, with realistic estimates.   

BDD directly influences the design of the software, while TDD is focuses on the testing. So we can say that TDD focuses on the implementation aspect of the system while BDD, as its name says it, focuses on the behavioural aspect of the system. The priority is not about how it will be implemented but more about what will the user be able to do and what he will be able to see.

So which is better? None. They should be used together!

I think it’s obvious that if I write an article about Behavior Driven Development, there are benefits I would like to mention!

 

A few benefits you get by doing BDD

 

• Strong collaboration. With BDD, all the involved parties have a strong understanding of the project and they can all have a role in the communication and actually have constructive discussions. BDD increases and improves collaboration. It enables everyone involved in the project to easily engage in the product development cycle. And by using plain language, all are able to write behavior scenarios.
• High visibility. By using a language understood by all, everyone gets a strong visibility into the project’s progression.
• The software design follows business value. In fact, BDD puts a great importance to the Business value & needs. By setting priorities with the client, based on the value it provides, developers are able to provide better result because they have a strong understanding of how the client thinks. By focusing on the value, no useless features are built.
• The ubiquitous language. As mentioned earlier, the ubiquitous language is understandable by all the members of the team, which reduces misconceptions and misunderstanding and makes it easier for new members to join the working process.
• Software development meets user need. By focusing on the business’ needs, you get satisfied users, and that implies a happy business of course. Actually with BDD, as its name says it, you focus on the behavior, which has a stronger impact than the implementation itself. 
• More confidence from the developer’s side. Teams using BDD are in general much more confident that they won’t break code, and have better predictability when it comes to their work.
• Lower costs. By improving the quality of the code, you are basically reducing costs of maintenance and minimising the project’s risks.