There is a general misconception that behavior-driven development (BDD) is an extension of test-driven development (TDD) and that when BDD is used, the team doesn’t have to use TDD and vice versa. In this article, we will be looking at how BDD and TDD can be used in an agile project, the difference between BDD and TDD, who should be responsible in BDD and TDD environments, and how you can automate BDDs in minutes and without code.
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.
What is BDD?
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.
Before we look at how BDD and TDD are used in an agile project, let’s look at the issues the team will face when BDD is not put into practice properly.
Agile without BDD
“The hardest single part of building a software system is deciding precisely what to build” – Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering (1975)
In an agile environment, the development process typically starts with a user story, then the design, then development, and then testing would start. This is depicted in the diagram below. The issue with this approach is that the team that actually implements the solution doesn’t get involved in the requirement capturing phase. Usually, this is done by the product owner or the BA. As a result, team members are more likely to implement a solution that is incorrect, or at best, buggy.
Another issue with this is that the three amigos are on a different page, as there is no collaboration to get a common understanding. Furthermore, the test cases written by the QA to test whether the implemented solution adheres to what the BA or the product owner defined is written in a technical language not understood by the non-technical members of the team (typically the BA/product owner).
BDD and TDD in Agile
In an agile project, BDD starts at the point of formulating the requirements. The team (mainly the three amigos) collaborate and discuss the requirements. This is quite critical in software development, as the team that actually implements the solution takes part in the requirement formulation, and as a result the ambiguities are reduced and the team will have a clear understanding of the requirements. Moreover, the different team members, technical and non-technical, will be on the same page.
After the collaboratively formulating and accepting the requirements, the team defines scenarios needed to fulfill the requirements. These scenarios are written in the Gherkin language, which is nothing but a plain language with specific format Gherkin language typically starts with certain keywords; Given, When, Then, And and But. A sample BDD scenario using Gherkin language is given below:
In order for the entire team members to understand the requirement well and to keep all the team members, functional and non-functional, on the same page, BDD should be employed at the start of the development process, allowing the team to discuss and define all possible scenarios written in a ubiquitous language that is understood by both functional and cross-functional members of the team. This improves the quality and time of delivery significantly, as different team members know exactly what has to be developed/tested up front without any ambiguities or misinterpretation. By discussing, defining, and agreeing on the scenarios up front, any bugs that might get introduced into the system during the development process due to misunderstanding of the requirements are prevented. The following diagram shows the development life cycle using BDD:
The derived scenarios serve as the 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 owners use the scenarios to validate whether the product is implemented as the business expects.
How do BDD and TDD Work together?
TDD is written by developers and is done before the code is implemented. 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 it better.
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. The differences between BDD and TDD are explained in the following section.
Scenarios are derived through collaboration between team members
Implemented by developers
Scenarios are written in natural language
Written in a programming language
Created and maintained by entire team
Created and maintained by developers
Tests the end to end behavior of the application
Tests are written for individual function
BDD vs TDD – Summary
Can QAs write TDD?
As we have seen above, TDD is a development process where the developer writes unit tests before developing their code. This allows the developers to better write, easily test, and refactor the code until a better code standard is achieved. TDD is exclusively a developer activity. The purpose of TDD is to roll out a better quality code, which is bug free. Having QAs writing tests defeats this purpose of rolling out TDD, as the person who writes the test and the person who implements the solution (i.e., the developer) have different perspectives. Since the developer is detached from writing the tests, they wouldn’t have the holistic view, and as a result, might end up developing code that may not be of a high standard.
Who Writes BDD?
Unlike TDD, BDD is a collaborative process, and as a result the entire team takes the responsibility of deriving the scenarios. The entire team participates in discussing the user stories and deriving scenarios required to be addressed to make sure all acceptance criteria defined in the user stories are met. BDD is a cross-functional process. Having a single person owning the process of organizing the collaboration meeting, deriving scenarios, and automating the scenarios defeats the purpose of BDD. As part of the collaborative process, the team derives the scenarios, then the QA automates the derived scenarios and the developer implements the solution as per the defined scenarios. Once the solution is implemented, the product owner/BA makes sure the solution works as per the defined scenarios.
Automate BDD Scenarios in Minutes without code
Automation is one of the biggest benefit of using BDDs. The beauty of BDD is you can actually execute the derived scenarios to check if the implemented solution adheres to it. This is beneficial because what has been agreed on is written in a natural language understood by both functional and non-functional members of the team, so it can be better executed and checked that the application works as expected. Comparing this to an application which uses test automation in a traditional style, the automation script is written in a way that it is understood only by either a QA or a technical member of the team, and a correlation process has to be in place to make sure the automated script adhered to the derived scenarios.
Though BDD automation offers a huge benefit, it does take a considerable amount of time to automate and manage. On top of that, automation engineer roles are not easy to fill. As a result, BDD automation is often expensive and time consuming. We created NoCodeBDD mainly to address this issue. Using NoCodeBDD, you can automate BDDs in minutes and without code. All you have to do is write your scenarios and provide some information using the NoCodeBDD user interface (UI) and BDD will take care of the automation. The following video shows a sample of how a REST API is called and a database is checked for results. You can download a free version of NoCodeBDD from www.nocodebdd.com/download
Using both BDD and TDD should be considered to improve quality of the product. BDD should be considered at the start of the development life cycle as a requirement capturing process. It is essential for the team to collaborate and derive the scenarios collectively. These scenarios are the specification, which the entire team refers to: developers use these scenarios to implement a solution and QA uses these scenarios for testing. Using NoCodeBDD, Test Automation can be achieved in minutes and without writing any code, so the team can spend more time on actual testing and less time on writing automation scripts. NoCodeBDD can be downloaded for free from www.nocodebdd.com/download
I had the pleasure of hosting a webinar with two industry experts, Rebecca Stone from IBM. During the webinar, Rebecca shared her experience in successfully implementing BDD in a large government project, highlighting the benefits of BDD, why and how she used OOPSI and its role in overcoming challenges faced […]
Rolling out BDD in a project requires careful planning and a well-structured process. As a tech consultant on a large project, I had to make several changes to their BDD process and automation suite implementation. Some changes were straightforward, while others proved more challenging. If you’re considering implementing BDD in […]
10 Tips for Writing Effective BDD Scenarios When rolling out BDD having a clear and concise scenario writing is a vital aspect of successful BDD adoption. This blog post will provide you with 10 tips to enhance your BDD scenario writing, making it easy to understand, maintainable, and efficient. 1. […]
It will be difficult to automate testing if you don’t consider it when creating your web application. It will be difficult, regardless of whether you are a code wizard or a no-code ninja. Here are some crucial ideas to have in mind as you develop your app to make testing a […]