TDD or BDD: Choose for Yourself

Product development always begins with planning. Planning helps the developers give direction and determine the motives in a better way. In the earlier days, we would collect the requirements, distribute the development tasks and begin the development process. As a next step, we would test the software, put the issues, and develop again.

Although that worked well in the past, the researches and building project complexities have given birth to two new theories used in the planning phase today: TDD and BDD. TDD and BDD are the development processes that appear during the start of the development and do the same work of shaping our development work. 

While TDD and BDD have been around for a while, people tend to mix both the terms generally. Whenever someone questions, “What is the difference between TDD and BDD?”, the majority of the testers can’t solve this puzzle. Being the two most common design techniques and foundations for test cases, I feel the need to declutter this condition so that you can answer that simple question in the future. 

What is TDD?

TDD stands for Test Driven Development and the name talks for itself here. When the development of the software is managed through the tests, we term this procedure as TDD. In TDD, we begin with the tests first which are based on the requirements or understanding of the software, and then proceed on to the development part. For example, if I know the software needs alphanumeric as a password, I can create a test around that before the code. Usually, the tests would fail because even though we know the functionality while writing the tests, the code has not been made in the same way. What do we do then? We refactor the code according to the tests until the test cases are qualified and we are satisfied.

TDD process

To understand the test-driven development procedure, in the example below, we will try to create a software that returns “True” when the number given is divisible by 3.

As a rule, we will begin with a very simple test to check if “1” passes the tests or not:

@Test

String Outcome = Func(1);

Assert.equals(“False”, Outcome);

In another file, I will write my code as follows:

String Func(int number){

   return “True”

}

The test case will fail because no matter what the number is, the Func() will always return “True”. This means we are not executing the code rightly and is a call for refactoring. We refactor the code to “False”:

String Func(int number){

   return “False”

}

Now my test case will pass as the required value is the real value. As a next step, I test with the number 2.

@Test

String Outcome = Func(2);

Assert.equals(“False”, Outcome);

This test case will pass too as the result is again “False”. At this point, we might think that this is the right implementation of the software but the more test case you write, the better quality of the software will be written. Hence, I examine for 3 now.

@Test

String Outcome = Func(3);

Assert.equals(“True”, Outcome);

This test case fails! Now we require to refactor the code. Maybe the value “True” is expected only for a number 3. So, I refactor my code accordingly as follows:

String Func(int number){

if(number == 3)

    return “True”;

return “False”

}

Now when I run all the test cases (1, 2 and 3), all my test case passes. I am on right track now. As a tester, I understand that since the test case passed for 1 and 2, they would pass for any number except 3. So, I take 6 now as the input and write a test case as follows:

@Test

String Outcome = Func(6);

Assert.equals(“True”, Outcome);

Again, my test case fails as the number is not 3 and since the “Outcome” is “False”. I need to refactor my code again at this point. I perform some new changes to my code as follows:

String Func(int number){

if(number % 3 == 0)

    return “True”;

return “False”

}

This will end in a successful test case on all the numbers. After repeated refactoring, we have completed the function implementation according to the tests. Therefore, we call it a test-driven development. Seldom, this is also called a “Red-Green” approach or “Red-Green” testing because the test fails (Red) and then passes (Green).

Benefits of using TDD

There are a lot of benefits of the TDD approach:

Better Quality Software: From the example above, it is noted that our repeated refactoring will end in a better quality of software. Since we are developing according to the tests, the elements are already checked and satisfied.

Faster to Develop: A lot of the time, you would discover that TDD takes more time in development, sometimes up to 30% more. While that is really true (not committing to any absolute numbers), it is simply half of the story. When we find a bug at production and try to fix it, it costs us 100 times more than what would have been the cost at the time of requirement collection. As a matter of fact, TDD decreases the production bugs density from 40% to almost 80%. This suggests our cost and time are being saved as the majority of the bugs are rectified before production. Hence, if we take that into consideration, TDD actually helps in developing a product faster, bringing down the time to almost half!!

Easy To Maintain: TDD helps in easy maintenance of the software as it decreases the production bugs up to 80%. When the troublemaker is out of the way and an already refactored code is given to the production, there are very less reasons to worry about the maintenance.

Project Costs are Reduced: As described in the second point about faster software development, a project’s cost grows to 100x when we require to fix the bugs in production. Since TDD decreases these bugs, we get a reduced project cost and a happy client.

What is BDD?

Another type of development approach is Behavioral Driven Development. By now, I am sure you must have already figured what BDD is in comparison to the TDD strategy. BDD approach works towards the behavioral aspect of the development. In BDD, we begin with describing the expected behavior of the system and then write code respectively. An illustration of behavior can be, “if the customer is above 60 years of age, decrease the interest by 2%”.

The strength of the BDD strategy comes from the mode of communication used in it; plain simple English. Like English helps in bridging the passage between people in various parts of the world, BDD bridges the gap in non-technical and technical people working on the same project. BDD employs an informal procedure and needs no technical knowledge in constructing the documentation. The method of BDD begins with a simple discussion between the client and the manager/analysts in order to know the requirements and the software they require to develop. The next stage comes with documenting some examples that meet the requirement for the client’s assurance as well as for the coder’s reference. The last stage is to code the requirements and test them with more tests and examples.

The following test represents the BDD approach for banking (or an ATM) software:

Money Transfer Changes Balance in Account

As an ATM cardholder

I can transfer money from Account

Transfer changes the balance

Given that I have $100 in my account

And my friend has $200 in his account

When I send $50 to my friend’s account

My balance reduces to $50

My friends balance increases to $250

The BDD language can be read, formed, and updated by anyone from the technical or non-technical team. The greatest strength of BDD is that the customer can read this language and learn if his requirements are accurately understood or not. Similarly, developers know the requirements clearly too.

A BDD test constitutes of three sections:

Context: This is the story or overview of the situation. In the example above, “Money Transfer Changes Balance in Account” is the context.

Event: An event is a behavior you require in the system. In the illustration above, the following is the event:

As an ATM cardholder

I can transfer money from Account

Transfer changes the balance

Outcome: The final section is the example section describing the expected outcome of the event. In the above case, the following is the outcome:

Given that I have $100 in my account

And my friend has $200 in his account

When I send $50 to my friend’s account

My balance reduces to $50

My friends balance increases to $250

BDD is an outstanding way to document the system behavior and utilize it in place of unit tests because unit tests are very hard to execute when the system is completed or already exists. Comprising a large audience under it, BDD tests are also a better option than TDD as it enables a greater feedback loop (including the client) and other business and managerial employees. The only dilemma with BDD is that when something goes incorrect in the tests, it is hard to determine what went wrong and at which location. This also enhances the overall project development time.

Benefits of using BDD

BDD brings loads of benefits with it, which makes it a common option in the organization. The most important benefits are summarized below:

Wider Involvement: Collaborations are always acknowledged while writing the software, particularly tests. With BDD, we not only collaborate between the testers and developers but also product managers and analysts, and even customers into our team. The bigger collaboration helps in better communication among the teams and a good understanding of what to develop with what behavior.

Clear Objectives: Simple English instructions make the goals clear in the developer’s and tester’s mind which earlier would seldom be twisted in various layers of communication.

Better Feedback loops: BDD includes more people collaborating on a project. Therefore, there are more eyes that can understand the tests and hence more fingers to transcribe the feedback.

Lower Costs: Since the development is driven by the tests, the process reduces the chances of bugs in the later stages of the project (especially production) cutting down the overall cost of the project development.

Confident Team: A beneficial outcome of having clear objectives is that the team is positive in the overall process as they know the requirement of the project precisely. Confidence helps in delivering the best out of them during the development.

Shift Left: BDD begins with the behavioral scenarios of the system which provides a direction to writing automation tests very beginning into the process. Early automation tests are directly accountable for lesser bugs in the later stages.

Conclusion

I hope this post helps you choose which path to take while starting a project in the future. As a tip, I can tell that sometimes, you can begin with both of them if the requirements satisfy this approach. There is no harm in using both procedures or sometimes using none of them. Seldom just unit tests and integration tests are sufficient for your project. There is no standardized “best” method here and it depends completely on the project.

TestUnity is a SaaS-based technology platform that is managed by a vast community of tester and QA spread around the globe. We give an end-to-end software testing cycle and ensure the best results. Testunity operates with a mission to bring down the cost of testing without endangering the quality of the product. TestUnity has expertise in all testing domains and processes. We will help you in getting better and efficient testing results without spending much of your software testing. Testunity helps in producing the project on time and without any bugs or issues without the requirement to spend much on testing. Contact us now to get in touch with one of the most efficient software testing company in the world.

TestUnity

Testunity is a SaaS-based technology platform driven by a vast community of testers & QAs spread around the world, powered by technology & testing experts to create the dedicated testing hub. Which is capable of providing almost all kind of testing services for almost all the platforms exists in software word.