Explained: TDD vs BDD

If you here reading this then you must be aware of the transition of software development from waterfall to agile over the past decade. Agile needs continuous change and has brought testing to the forefront to ensure quality is not an after-thought. The debate of TDD vs BDD has its roots in shift towards customer-centric software design. 

Ask any developer and they must be aware of test-driven development (TDD) technique. However, there is a chance they may not know as much about behavior-driven development (BDD) approach. Both the techniques come with its own upsides and downsides.

We are going to deep-dive into both the approaches and do a comparative study of their pros, cons and differences. Let’s get started with analysis of TDD vs BDD! 

What is Test-driven development (TDD)?

It is a software development process that repeats short development cycles. Simply put, codes are written for a specific functionality and tests are repeated unless its passed. When following this method, developers are confident that the code does the job accurately. This process improves the code quality and eliminates any technical debt. The entire life-cycle of a TDD is often referred to as the red-green refractor cycle.

Refer to the image below and you would clearly see the cycle. A developer can start with a failing test and modify the code where necessary to fix the error and make the code green. The refractor stage – changing or adding parts of the existing code, without affecting the behavior of the entire code – too plays a vital role in the TDD method.

Kent Beck, a unit testing pioneer used the TDD approach. What we also think worth explaining is the bottom-up and top-down TDD approach.

Bottom-Up TDD

Also known as the inside-out TDD, this approach builds functions iteratively – building one entity at a time. It targets to pick a function and solidify its behavior before moving on to the next one. One could say that it builds everything in layers. It is most likely to start by scripting the unit-level code, followed by its implementation. Further, it would go on to write high-level test that solidify the functionalities of the lower-level tests and so on.

The layered approach eventually gets to a stage where the highest level test remains just an acceptance test. The bottom-up TDD approach is known to be highly developer-centric and functions around making their lives easier.

Top-Down TDD

Also known as outside-in TDD method, this takes the opposite route to the bottom-up approach by starting to build a system and adding details to the process through it. It requires a series of steps to be repeated, while being tweaked and improved with each cycle. The entire idea behind this being breaking each step into smaller entities, which starts with writing a acceptance-level test and proceed with minimal implementation.

This test needs to be done incrementally and hence before building any new entity, it requires tests at appropriate levels. This approach is more business or customer-centric and is relatively more complex as it relies heavily on seamless communication between parties. Nonetheless, the pros to this approach outweighs the cons. If done successfully, the approach results in a clearly-defined system, flows and a predictable workflow and outcome.

What is Behavior-driven development (BDD)?

We might have successfully explained the bottom-up TDD approach, which is developer-centric and produces better code-base and test suite. On the contrary, the top-down TDD approach is more customer-centric and produces overall better results. Dan North, with his experiences with both the TDD approaches proposed bringing together the best aspects of both and introduced the BDD approach. The new development approach eliminated all the shortcomings of the two and helped with more valuable testing behavior than functional testing.

In a tweet Dan North explained BDD as, “Using examples at multiple levels to create shared understanding and surface uncertainty to deliver software that matters.”

This technique requires different parties to collaborate through the project delivery timeline. It needs a developer, test engineer, product manager and other stakeholders to define and formalize a system’s behavior to a common, domain-specific language that is understood by all parties. It then goes on to use this definition to write an executable test.

BDD thrives on a successful direct collaboration between the team and the customer. It becomes vital that the system’s behavior is defined correctly to run accurate behavioral tests. One common practice is to assume the behavior of the system. This usually occurs when a test is run keeping in mind the implementation detail, making it a functional test and not a behavioral test. Bear in mind that the BDD-based approach must result in a full test coverage where the system’s behavior is vividly described to all parties by using a common language.

TDD vs. BDD: Similarities

We’re now going to summarize the main differences and similarities between the two approaches.

Let’s begin at the start. In TDD, the process starts by writing a failing test case. In BDD, you kick off the process by writing a scenario, in plain, human-readable English.

Both TDD and BDD aren’t testing methodologies—that’s a common misconception. They are software development methodologies that revolve around automated testing.

Both approaches achieve the result of having a comprehensive suite of automated tests covering the application, even though that’s certainly more pronounced with TDD.

TDD vs BDD: Key Differences

If we were to compare TDD vs BDD directly, we would say the main differences being:

When people ask what’s the difference between TDD and BDD, this question is often the main discussion point. In TDD, you have a test method that will assert some states, but these tests may give false results as the system evolves. But in BDD, you are looking at behavior, such as what will happen to this system under certain conditions.

A simplified difference between TDD and BDD are expressed below:

“In TDD, I’m not concerned about the output. The only thing needed is to carry out the test in a particular way.”

“In BDD, I don’t mind how you come up with the output, except the output has to be correct under the given condition.”

TDD vs BDD - Which Route to Take? 

Understanding which approach would work better for a task at hand is the right approach. More often than not, the solution would lie in both the approaches. In larger projects there might arise a need to adopt both the development techniques at different stages of the project life-cycle.

TDD might be a more developer-friendly choice, benefitting the technical team, whereas BDD will focus on driving better communication between all parties involved and deliver a customer-friendly result.

The TDD vs BDD decision depends on the individual organization and the application. If a team is already doing TDD, they may want to experiment with BDD by using it for a small feature to see how it adds value to their process. 

There is no one-stop solution to everything, the knowledge and understanding of both the development techniques will allow teams to make better decisions so as to which method is best for a given project.