The tech industry is teeming with acronyms, phrases, and buzzwords. It’s impossible to stay up to date on everything, and it’s easy to miss the latest trends. When we look into the agile sphere, we can observe a lot of questions and discussions around TDD vs BDD vs ATDD. In this article, we’ll discuss what these acronyms stand for and whether you should incorporate them into your app’s development workflow.
What’s TDD and How Does It Work?
As the name implies, Test-Driven Development (TDD) depends heavily on writing tests. More specifically, you write tests (in the form of unit tests) before writing a single line of code. You may also have heard that TDD focuses on answering the question, “Is the code correct?”. This means TDD is very developer-oriented – an essential aspect of this method you need to recall when we talk about BDD and ATDD later in this article.
But how does TDD work? In a nutshell, you follow these 6 steps:
- Create a test. Take one of your app’s requirements and create the needed tests. This way, your team doesn’t jump right into programming but has to go deeper into the given specification.
- Run the tests and see if they all fail. You haven’t written any code yet, so all tests should all fail. If tests pass, you already have similar functions in your project and need to investigate whether you can reuse them.
- Write the code. Now it’s time for your developers to bring the feature to life!
- Test the code. Rerun your tests. Do they all pass? If so, you have completed the development of the feature and met all requirements.
- Refactor. Time to clean up the code and make it more efficient by following your company’s code and style guidelines.
- Repeat the steps. This last step is only needed if your team needs to implement a new feature in the existing component, or if the requirements have changed.
Your team works through these steps for every requirement and every piece of code it writes.
Developers unfamiliar with the process may struggle with this concept at the beginning. They are used to writing tests after writing components, not before.
However, practice makes perfect, and once developers master this method, the quality of your app improves significantly. Your code contains fewer bugs and becomes more stable. It also makes it easier for your team to implement new features or extend existing ones. This means your application also becomes more flexible and extensible, potentially leading to faster time-to-market.
What’s BDD and How Does It Relate to TDD?
Rather than focusing on testing the implementation of code, Behavior-Driven Development (BDD) aims to validate scenarios and behaviors. However, you may find some similarities with TDD. For example, you also follow the six steps described above to ensure that quality code is created.
The main difference between the two methods is how test cases are written. In BDD, not only the developers have to think about what they want to test. Developers, testers, and the product manager (or another business expert) come together, review each user story, and think about how to ensure the criteria of each user story are met. The team then writes down these examples in a specific language, such as Gherkin, which is a domain-specific language, created explicitly for writing behavior descriptions. This language follows a specific syntax, which uses the Given, When, Then keywords to describe what should happen when in the application. Since you use a natural language, such as English, anyone can read and understand these specifications. Then, you use automation tools like Cucumber that enables you to execute the created specifications for testing.
For developers, a key advantage of BDD is that they do not have to rewrite tests each time they rewrite their code. That’s because BDD is not focused on the code but on the behavior of the app. Anyone involved in the process can understand and process the test cases because of the non-programmatic language. Individuals, such as business experts, can ensure that they communicate the key aspects of effective application behavior. By discussing requirements, collaboration becomes more enjoyable, and everyone involved can work towards the common goal.
What’s ATDD and What Role Does It Play in Agile Environments?
Acceptance Test-Driven Development (ATDD) is an extension of TDD and works similarly. Robot Framework is one of the most popluar test automation framework used for ATDD.
However, ATDD requires high-level tests to ensure the app’s functional specifications are met. The ISTQB defines acceptance testing as:
“Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.”
Furthermore, ATDD and BDD often get used interchangeably – let’s discover why!
Like in BDD, a team of developers, testers, and business experts team up, defining test cases to make sure features work as expected. Typically, ATDD doesn’t use the Given-When-Then syntax, but there’s no reason why you can’t use it in ATDD. Acceptance tests are created from the perspective of a user and answer the question: “Does the app/system do what it should?”. The next steps are the same as with TDD and follow again the 6 steps described above.
Again, you can increase the efficiency of collaboration through improved communication. The team must talk about the desired behavior of the final product and make joint decisions on equal terms. In this way, you can prevent misunderstandings and ensure that the desired result is achieved.
TDD vs BDD vs ATDD – What to Go For?
Now let’s talk about their relationship and relevance to agile teams. Depending on what you need, you may not have to stick to one method. Instead, you can use a combination of all three or only pick the best fitting parts of each. Most times, agile teams don’t apply methods by the book and tailor it to their needs. If possible, do what works best for you and your team, not what a specification dictates.
Let’s look at some ways you can integrate the methods into your agile team.
The Power of Combining TDD and ATDD
Of course, you could use either TDD or ATDD. However, the benefits of bringing them together are straightforward to comprehend. While TDD requires unit tests, ATDD uses acceptance tests. In other words, when you combine TDD and ATDD, you are creating low-level and high-level tests for your application. To develop and release robust, high-quality applications, you need tests at different levels. Use TDD to make sure your code is working, and to achieve 100% test coverage. ATDD helps you ensure the app’s behavior is spot-on and leaves a good impression with your customers.
How Can You Use BDD and ATDD Together?
You’ve probably noticed that ATDD and BDD are super similar, and some industry experts even use the terms synonymously. However, the most crucial component of BDD isn’t the tools but the conversations you have around your app’s requirements! On the other hand, ATDD is more developer-oriented than BDD – just like TDD. To improve your application’s quality, you should bring together the three amigos: business, dev, test. Make sure they are all on the same page and know the requirements of the app. Again: Communication is vital for agile teams and BDD! If it makes sense for your workflow, make use of BDD’s Given-When-Then syntax to create test cases in your natural language. Create acceptance tests to make sure, the system performs as expected in certain situations.
It’s Not About TDD vs BDD vs ATDD – Think About How You Can Use Them Together to Your Advantage
Finally, when you combine the three, you don’t only write tests from the code-focused view of a developer. You get more people on board, having conversations, making sure everyone can contribute to the app’s quality by sharing their specific insights. As a result, your application fulfills its requirements, and you make your product development cycle more efficient. Also, your app’s code contains fewer errors. This allows your QA team to focus on more challenging tasks or manual test cases. All in all, everyone in your organization can spend their time more efficiently by combining TDD, BDD, and ATDD.
Image by Goumbik via [source link] (copyright-free)