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.
Advantage of TDD over the Traditional Approach
In the traditional development approach first, you select a user story, then develop it, run tests over it and refactor the code until the test is passed. In this method, the coding is done before testing. The disadvantage of using this approach is that you are unable to discover the errors or missing cases until the functionality has been fully developed. With TDD, you write tests upfront for functions that doesn’t yet exist. You know that the test will certainly fail at the start, but minimal incremental coding at each stage will make sure it will eventually pass at some point. So, this process makes sure you won’t miss any scenarios once the functionality is fully finished.
Benefits of TDD
With TDD, tests will be automated, saving a lot of time compared to manually testing functionality.
With TDD, tests are created for each bug. These tests will be run each time there is another bug fix. This is to make sure bugs don’t reoccur in the code.
Because tests are in place upfront, regression testing time can be reduced considerably.
Tests written ahead of time will also ensure good code quality.
Writing tests, followed by minimum code changes after each test run will make sure there is good unit test coverage for the software, which will again contribute to the overall quality of the product.
Drawbacks of TDD
Developer can consider it as a waste of time
The test can be targeted on verification of classes and methods and not on what the code really should do
Test become part of the maintenance overhead of a project
Rewrite the test when requirements change
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:
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, etc. The test scripts are written in plain English in Gherkin, Wiki frameworks, etc. 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.
TDD vs. BDD
BDD is in a more readable format by every stake holder since it is in English, unlike TDD test cases written in programming languages such as Ruby, Java etc.
BDD explains the behavior of an application for the end user while TDD focuses on how functionality is implemented. Changes on 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, in which case TDD better serves the purpose.