Blogs

Best practices and trends in technology

Our Take on TDD/BDD - Which One Do We Prefer?

Nov 17, 2017

In order to keep ourselves updated with the latest software development practices, we ought to choose between the Test-driven development (TDD) and Behavior-driven development (BDD). This blog post is meant to explain what TDD/BDD mean, the steps followed in each of them, the preferred one and the reason for it?

Test Driven Development (TDD)

TDD is a one of the best software development techniques which involves writing the automated test cases before writing functional pieces of the code. This technique is popular in agile methodologies as it drives, delivering a shippable product at the end of a sprint. It is also considered as a programming technique. The main aim of TDD is to write clean code that works.

2. Run all tests and see if the new one fails: Development team runs these automated test scripts against what is currently developed and lists the failed test cases. There are various numbers of failed test cases as none of the features have been implemented yet.

3. Write some code and again run test cases: Development team writes functional code and again executes the automated test script until they are all passed.

4. Refactor code and Repeat: The development team can then organize and refactor the code in order to achieve a tested deliverable at the end of the sprint.

Behavior Driven Development (BDD)

BDD is also one of the software development techniques which involves writing user behavior and specification before writing test automation scripts or the functional pieces of code. Behavior-driven development focuses on the business behaviors your code is implemented. The Agile product owner or a business analyst sit together and write pending specifications in a plain text. The business person specifies behaviors they want to see in the system.

This involves the following steps:

1. The behavior of the user: First, the behavior of the user is defined by a product owner or business analyst.

2. Convert to Automated scripts: These are then converted to automated scripts to run against functional codes.

3. Write some code and again run test cases: Development team writes functional code and again executes the automated test scripts until they all are passed.

4. Refactor the code and Repeat: The development team can then organize and refactor the code in order to achieve a tested deliverable at the end of the sprint.

The truth is that despite of using TDD for decades; TDD is still loved and hated in almost equal measures. At Seasia Infotech, currently, we have more Quality Assurance testers than developers working on a project. Earlier, the regression testing done was quite unsustainable. There also happened live releases in every 3 months along with emergency fixes, despite all the countless hours of QA tests that were done. Additionally, the Code coverage also increased over the months, along with the ratio of the automated to manual testing. Yes, TDD is dead for us, but we should honor its contributions than lingering on the travesties. It marked an important phase in our history, but it's time to move on.

At Seasia Infotech, we prefer BDD over TDD because BDD is written in a more readable language i.e. English, which is easier to understand for a Product owner while in TDD test cases are written in programming languages such as Ruby, Java etc. BDD focuses more on the behavior of an application for end user point of view while TDD focuses on how the functionality is implemented. BDD is also less impactful as compared to TDD in case of functionality changes.

In our opinion, for systems such as eCommerce or HR system, BDD would be a good option, as it acts a good medium to capture all the user actions. For systems that require third party API calls, jobs, data and exports/imports, TDD might be a better option.

About Author

Yashu Kapila is working as Vice President at BugRaptors. The best part of her role is managing key client relationships, setting up and building large testing services and release for projects spread across the globe. She has diverse experience in release management, consulting, operations and presales. She holds the expertise in SDLC, Project management, Process Definition, and CMMi. She is also involved in creation of WBS, test plans, user requirements study, part of wireframes, resource allocation, daily scrums, monitoring and control. She drove CMMi L5 v1.3 initiative with successful implementation of the model.