TDD & BDD Explained

TDD & BDD Explained

Ensuring the quality of the components of a software product is a big deal. In this article, we tell you what are the BDD and the TDD approaches, and what are the differences between them.

The definitions at first

What is BDD?

BDD is the acronym for "Behavior Driven Development" that is, development directed by behavior, which is an evolution of TDD or "Test Driven Development".

BDD was born from the hand of Dan North thanks to his need to test ‘behaviors’ through the tests he did. This concept finds good use in the next case – let's say that the concept of “test” fell short, and you discovered that if you described the behaviors you wanted to reproduce with the tests, it was much clearer for future developers what you were trying to check and what happened if something went wrong.

BDD is an Agile methodology that applies to the entire software development process. The tests become 'scenarios' or 'behaviors', described in a natural language that can be easily interpreted by everyone, from the business side to the developers.

What is TDD?

From Test-driven Development, TDD is an approach to software development where you first write the tests and then use these tests to design your application and develop it.

TDD, as one more tool in your toolbox, can help you validate the tests that you have prepared. If, on the contrary, you program before the tests, you will have to do the validation manually and we already know what happens when the system scales.

So, what are the differences between them?

If we read the definitions of TDD and BDD they seem to be the same thing, the main difference between the two is in scope. TDD is a development practice (it focuses on how to write the code and how that code should work) while BDD is a team methodology (It focuses on how you should write that code and how that code should behave).

In TDD the developer writes the tests while in BDD the end-user (or PO or analyst) together with the testers write the tests (and the Devs only generate the code necessary to run those tests).

If we compare the 2 we can say that TDD deals only at the unit level or a small amount of the applications under development, BDD will take care that the tests on the integration of those units at a business level so that they are not only tests but they are also living documentation of the application available to any user and in the same language (terms that are commonly used).

It is important to know that BDD can also be considered to be applied at the unit level (methods), as there is nothing to prevent the use of BDD to supplement/replace TDD and instead of writing Given-When-Then for integration tests, we can use the same at the unit level and thus complement/replace the tests in TDD.

So what to use – TDD, BDD?

Breaking it down – if you need quick feedback of your code then you can use the TDD. If you need to know that the different portions of code developed are integrated as expected then BDD is a good solution for you. Besides that, BDD contributes to knowing that you are developing the right thing.

So, as you can see, although TDD or BDD look very similar, the main difference between the two is in scope. TDD is a development practice, focused on how to write the code and how it should work. Whereas BDD is a team approach that emphasizes why you should write that code and how it should behave.

In TDD the developer writes the tests while in BDD the end user, together with the rest of the multidisciplinary team, writes the tests.

Our recommendation will support both solutions: TDD and BDD. If you can involve the entire organization (clients, users, and management with a BDD approach), they will generate very enriched user stories with which you can define a minimum viable product (MVP), in addition to aligning the development objective and the digital strategy among all those involved.

Once everyone is aligned, it will be the best time for the technical director or the development team to establish a TDD approach, with which you can anticipate and define the main technical characteristics of your development in much more detail, anticipating the programming errors that the end-user might experience.


The secret to ensuring that your development does not become defective software for the end-user is to ensure that the tests and the definition are established by the entire team involved, from the end-user, managers, and, of course, the development team. Digital innovation is not just about the technical team. Only then will you guarantee proof from all business perspectives.

The sum or the choice between TDD and / or BDD will depend on the needs of your project, budget, deadline, etc. But remember that doing things twice is much more expensive than coming up with a good starter project, even if it's just an MVP.