by Jerome Josephraj
Share
Test-driven development (TDD) is a software development process in which the developer writes a test for a given function, then writes enough functional code just for the test scenarios to pass. Then, if required, the developer refactors the code to make the code better.
Behavior-driven development (BDD) is an Agile Software Development practice, which encourages cross functional members—mainly the three amigos, i.e., developers, QAs and product owner or BA—of the team to collaborate and derive scenarios in a ubiquitous language that is understood by all members of the team.
The derived scenarios serve as specification for the entire team. Developers implement the functional code for the scenarios; QAs write specifications/scripts for those scenarios to check whether the functional code works as per the agreed scenarios; and BAs/product owner uses the scenarios to validate whether the product is implemented as the business expects.
The BDD and TDD processes are depicted in the diagram below:
Though TDD and BDD both take the “test first” approach, there are several differences between BDD and TDD. These are explained in detail in one of my other article’s, BDD Vs TDD: What’s the difference? (+ Examples and Video). In the following sections let’s look at the advantages and disadvantages of TDD and BDD, with examples.
Short Summary of Advantages Vs Disadvantages for Software Engineers
The following tables summarize the advantages and disadvantages of BDD and TDD.
Advantages and Disadvantages of TDD Summary
| TDD Advantages | TDD Disadvantages | |
| 1 | Better code design and quality | Initial investment on time and resources |
| 2 | Fewer bugs | Not a silver bullet |
| 3 | Regression test suite | Requires cultural change |
| 4 | Easier to refactor functional code | Higher maintenance |
| 5 | Living documentation | |
| 6 | Reduced Time to Market | |
| 7 | Improves quality and saves cost |
Advantages and Disadvantages of BDD Summary
| BDD Advantages | BDD Disadvantages | |
| 1 | Collaboration | Automation is time consuming |
| 2 | Reduces ambiguities | Cultural change |
| 3 | Single source of truth | Increases maintenance |
| 4 | Shift left | Requires BDD expertise |
| 5 | Collective responsibility | |
| 6 | Automation | |
| 7 | Executable specification/Living Documentation | |
| 8 | Regression Test Suite | |
| 9 | Refactoring functional code | |
| 10 | Improves time to market and quality | |
Pros and Cons in Detail
Let’s look at the differences between BDD and TDD in detail:
Advantages of TDD for Software Engineers
1. Better Code design and Quality
The main benefit of TDD is to improve the code quality by following the process of writing test -> implementing functional code -> refactoring to improve code. The last step, i.e. refactoring, allows a developer to rework the code to the best programming design possible without spending much time on testing the function, as the tests are written at the start of the process.
2. Fewer bugs
Bugs are reduced, if not eliminated, as the functional code is written for tests. In TDD, the developer writes different scenarios to test the functionality even before writing the actual functionality. This results in lesser bugs as it encourage the developer to think about all possible scenarios before actually writing the code. According to a study conducted by Microsoft shows that the defects could be reduced from 40% to 90%.
3. Provides regression test suite
When TDD is followed for every functionality that gets implemented, more and more tests are written, resulting in a regression test suite. As new functionalities are written, the entire test suite can be executed to make sure the new functional code hasn’t impacted any of the previously implemented functions.
4. Easier to refactor the functional code
In TDD, since tests are written up front, it’s easier to refactor the code until code is implemented correctly—not only passing the test, but passing with the right design approach. TDD also allows for rewriting the entire code base or part of the code with a better design.
5. Living Documentation
Unit tests that are written as part of TDD serve as a good documentation. Developers usually refer to the unit tests as documentation to understand what the implemented functionalities are supposed to do. Though this is understood only by developers or someone who is technical, it still serves as a document of truth. Let’s look at an example to understand this better.
EXAMPLE
The following example shows unit test for a functionality. Can you go through the unit test (for the sake of brevity, the actual code within the method is not provided) and figure out what the functionality is? No price for guessing
public void test_username_doesnt_contain_special_char(){
}
6. ReduceS time to market
Though writing unit tests take time, in my experience it actually reduces time to market. Since the tests are written, whenever a functional code is changed, the tests could simply be executed to make sure the functional code is still behaving as expected. Lack of Unit Tests requires manual testing of the code, which is time consuming. Also, writing unit tests after writing functional code and not following the TDD process (writing test, then develop functional code, and then refactor to achieve best possible code design) increases time to market. As this would introduce bugs in the application and pave the way to bad code design, resulting in additional time to the fix the bugs.
7. Saves Cost
Though the developers spend time on writing and maintaining unit tests, this would only be fraction of the time spent if manual testing is followed. The cost of manual testing would grow linearly with the number of functionalities added to the application. Also, if TDD is followed properly—that is, tests are written before functional code—then bugs would be prevented in the first place, saving time and resources.
Disadvantages of TDD for software engineers
Though TDD brings some great benefits, there are some disadvantages as well, many of them due to poor practices. Let’s look at some of these disadvantages.
1. Initial investment on time and resource
According to one study by Microsoft, teams experienced a 15–35% increase in initial development time after adopting TDD; this might seem slower to start with, as the tests have to be written before the functional code. In environments, particularly start-ups, where the expectation is to get the functionality implemented as possible in order to give a demo to a customer or investor, this could be viewed as time consuming and thus as a disadvantage. But in the long run, rolling out TDD would actually save time.
Another disadvantage is writing unit tests for non-functional code, which will increase time to market and increase maintainability. I have worked on projects in which the quest to achieve 100% test coverage—mainly driven by someone who is not technical—has sacrificed good TDD practices, resulting in higher maintenance and higher time to market. Here is a great article from Martin Fowler related to this and how this affects software delivery.
2. Not a Silver Bullet
Though unit tests improve code quality and allow you to create bug free code—and though according to one study by Microsoft the defects were decreased between 40% and 90% relative to similar projects that did not use the TDD practice, it is certainly not a silver bullet. In order to achieve high quality software, the project still requires rolling out different test methodologies.
3. Requires cultural change of the entire team
In order to see the benefits of TDD, the whole team has to follow TDD. When the entire team fails to follow TDD and its best practices, poor code coverage and fragile tests abound, resulting in poor quality software, higher maintenance, increased time to market.
4. Higher Maintenance
There is also a higher maintenance cost, since there are unit tests to maintain. Any changes to functional code require changes in unit tests. This cost is even higher when unit tests are not written properly or the best standards are not followed.
Advantages of BDD for software engineers
1. Cross functional collaboration
One of BDD’s salient feature is collaboration of the cross functional team, and from a user story deriving different scenarios to testing in a common language that is understood by both technical and non-technical members of the team. I have covered How Behavior Driven Development (BDD) helps you overcome Muri, Mura and Muda in another article.
2. Reduces ambiguities
When teams collaborate and derive scenarios in a common language that is understood by both technical and non-technical members of the team, it reduces or eliminates ambiguities in understanding the requirement. When BDD is not used, different members of the team understand the requirement differently. Assumptions are made by different individuals of the team, mainly the three amigos (Dev, QA, and Product Owner), which gives rise to bugs in the system.
3. Single source of truth
The scenarios derived during BDD process are written in a plain language native to the team. The entire team refers to these scenarios: the dev implements the functional code as the scenario demands; the QA uses these scenarios to test the functional code; and the Product Owner or the BA uses these scenarios to check if devs and QAs have delivered the story as expected. So, for the entire team, the scenarios derived through the BDD process serve as single source of truth.
4. Shift left
In traditional application development, the testing is done after application development. This gives rise to a lot of issues; principally, bugs are introduced into the application and then identified. Shift left addresses this problem by writing the test before development. In doing so, the developers know what is expected so bugs are avoided during the development process. Here is an excellent article on Shift Left.
5. Collective responsibility
BDD is about collaboration between cross members of the team to derive scenarios for a given User Story. Since the team gets involved in defining the scenario, the entire team takes responsibility of the artifacts that come out of BDD processes. Unlike TDD, in which it’s the developer’s responsibility, BDD belongs to the entire team. This is a great benefit as it puts the onus on the entire team—not on individuals—which always results in a higher product quality.
6. Automation
One of the main benefits of BDD is automation. The scenarios defined during the BDD collaboration phase are used as a base for the automation scripts. In the case of NoCodeBDD, there is no need to write any scripts, as it automates the scenarios in minutes without you having to write any automation code. This is a huge benefit, as the entire application can be tested in minutes. This improves time to market considerably and improves quality of the software. It also frees up resources so they can focus on solving business issues.
7. Executable Specification
The scenarios that get defined as part of BDD are nothing but specifications. During automation, scripts are written against these specification so you can execute them, hence the name Executable Specification. This is a huge benefit, as any technical or non-technical members of the team can see what scenarios pass or fail and make sense of them. This is opposite to traditional automation, where the automated scenarios are understood only by the Automation Engineer.
8. Regression
When every user story is automated as part of the BDD process, it basically builds a regression pack. This is essential, if not mandatory, if you want to reduce your time to market, save cost, and improve the quality of your software. This also gives confidence to the entire team, not just the developer, that any changes to the functional code hasn’t impacted any other functionality. I have personally worked in many projects where we could literally get the health of our entire application in minutes through the BDD regression pack.
9. Refactoring
The automation regression pack allows the developers to refactor their code without being concerned about affecting or missing any business functionalities. Unlike in TDD, refactoring the code does not impact the BDD Scenarios, as BDD scenarios are not tied to code. This brings a huge benefit: the entire code base can be refactored and verified if the refactoring has created any bugs or affected any functionalities
10. Improves Time to Market and Quality
BDD, through its collaboration and automation, reduces time to market considerably. The collaboration process that is used up-front to derive the scenarios reduces or eliminates any ambiguities in the requirements. This provides clarity for the entire team, resulting in better quality software, and it reduces implementation time.
Disadvantages of BDD for software engineers
1. Automation is time consuming
Writing automation code takes time. Though many experts rightly argue BDD is not about automation, automation brings a huge benefit and is one of the main reasons for the popularity of BDD. However, the time it takes to write code to automate scenarios and maintain the code discourages many teams from using BDD—or the teams use a thin version of it (i.e., automate only few functions). This could be overcome by using codeless automation products like NoCodeBDD, which allows the scenarios to be automated in minutes compared to hours using products like www.cucumber.io—without writing any code.
Let’s look at a video showing how this disadvantage could be overcome by using tools like NoCodeBDD, which can be used to automate test scenarios in minutes and without writing code. The following video shows how a REST API could be easily automated in minutes without any code:
2. Cultural change
In order for BDD to be effective, it requires strong collaboration between different members of the team. This collaboration is possible only when the entire team adheres to the principles of the BDD process. The collaboration process should involve all three amigos. When a team member doesn’t participate in this process, then it reduces the efficiency of the BDD process. Here is one of my blogs, Reducing Muda, Mura and Muri, which explains how a properly executed BDD process can improve efficiency of software delivery and quality.
3. Increases maintenance
The assets created during BDD process, feature files and automation scripts, require constant maintenance. On an ongoing basis, it is important to keep the feature files up to date with the changing requirements. If you use scripts to automate your BDD scenarios, then they require larger maintenance tasks, like how the functional, live code requires constant maintenance. You could save time on maintaining the automation scripts by using codeless automation tools like NoCodeBDD and save considerable time.
4. Requires BDD Expertise
Rolling out BDD without prior experience does have an impact on the maintenance of BDD assets in the long term. Also, without proper training or expertise, it would be difficult to roll out an efficient BDD process and automated scripts. This can be overcome to an extent by using NoCodeBDD, which already has some of the best practices built into the product.
Conclusion
Though there are some disadvantages to using BDD and TDD, mainly due to poor implementation, the advantages outweigh them by far. Using both together will certainly improve product quality and reduce time to market in the long run. If you would like to know how you could roll out a lean process and improve efficiency through this lean process, take a look at Lean Process for Software Development: BDD to avoid Muri, Mura and Muda.
/
STAY IN THE LOOP
