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

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.

Decked is the set sequence of steps that is generally followed:

1. Write Test Case: In the beginning, the developer, based on requirement documents, starts creating automated test cases.

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.

You can check out [Agile Testing: A Faster Approach to Achieve Quality]

Is TDD Dead?

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.

The post Our Take on TDD/BDD – Which One Do We Prefer? appeared first on Seasia Infotech Blog.