Chances are you have heard of Test-Driven development (TDD) and Behavior-Driven Development (BDD) in software development. Below are definitions of both of these practices, including the major differences between the two.
Test-Driven Development (TDD)
TDD is a software development technique that involves writing automated test cases prior to writing functional pieces of the code. This is popular in agile methodologies as it drives delivering a shippable product at the end of a sprint.
This process can be divided into multiple steps:
A developer, based on requirement documents, writes an automated test case.
The development team runs these automated test scripts against what is currently developed and the tests fail, as they should since none of the features have been implemented yet.
development team functional code to ensure the automated test script gives them a green light.
The development team can then refactor and organize the code to produce a tested deliverable at the end of the sprint.
Test cases are mostly written in programming languages such as Java, Ruby, etc., and can be written using test automation tools such as Selenium, Watir, Windmill, etc. Since test scripts are written in programming languages, it is hard for a business analyst or test owner to verify the test scripts.
Behavior Driven Development (BDD)
BDD is a software development technique that defines the user behavior prior to writing test automation scripts or the functional pieces of code.
Used in an agile sprint, this method ensures that a shippable product is generated at the end of a sprint. This involves:
The behavior of the user is defined by a product owner/business analyst/QA in simple English.
These are then converted to automated scripts to run against functional code.
The development team then starts writing the functional code to ensure the automated test script gives them a green light.
The development team can then refactor and organize the code to produce a tested deliverable at the end of the sprint.
BDD can be driven by multiple tools such as Cucumber, FitNesse, PowerTools, Docker, and others. The test scripts are written in plain English in Gherkin, and Wiki frameworks. Since the behavior is defined in English, it gives a common ground for ALL stakeholders involved in the project. This reduces the risk of developing code that wouldn’t stand up to the accepted behavior of the user.
BDD explains the behavior of an application for the end-user while TDD focuses on how functionality is implemented. #Dev Click To Tweet
TDD vs. BDD
BDD is in a more readable format by every stakeholder since it is in English. Unlike TDD, test cases are written in programming languages such as Ruby and Java.
BDD explains the behavior of an application for the end-user while TDD focuses on how functionality is implemented. Changes in functionality can be accommodated with less impact in BDD as opposed to TDD.
BDD enables all the stakeholders to be on the same page with requirements which makes acceptance easy, as opposed to TDD.
The behavior of the application is the central idea in BDD; it focuses on the customer and pushes developers and testers to walk in the customer’s shoes. If actions do not affect the end-user, BDD might not represent such a scenario very well. If so, TDD serves the purpose better.
Like many other software development practices, it might not be feasible to identify what works for all projects universally. For systems that are driven by the actions of the end-user such as an eCommerce website or an HR system, BDD acts as a good medium to capture all the user actions. For systems that have third-party API calls, cron jobs, or data exports/imports, TDD might be the better solution.
