Test Driven Development, Behaviour Driven Development, Acceptance Test Driven Development
TDD3 is a software development technique. In this development technique, we create test cases1 first, and then we write the code underlying those test cases. Three important points to remember when talking about TDD are:
TDD process is simple and straightforward. We start by writing a test. We execute the test and watch it fail. We modify the code and re-execute the code. If test passes, we can either stop or add new test. If test fails, we modify the code until, the test passes.
TDD methodology follows a simple 6 step process:
Don’t be confused TDD or BDD with Domain Driven Design (DDD). Domain-driven design (DDD) is the concept that the structure and language of software code (class names, class methods, class variables) should match the business domain.
BDD is regarded as an extension of TDD where instead of writing test cases, we start writing executable specifications. Later, we write the code which is required to abide by these specifications. Four essential points you need to remember about BDD are as follows:
The process involved in BDD methodology consists of 6 steps and is similar to that of TDD.
Write the behavior of the application: The behavior of an application is written in simple English like language by the product owner or the business analysts or QAs.
Write the automated scripts: This simple English like language is then converted into programming tests.
Implement the functional code: The functional code underlying the behavior is then implemented.
Check if the behavior is successful: Run the behavior and see if it is successful. If successful, move to the next behavior otherwise fix the errors in the functional code to achieve the application behavior.
Refactor or organize code: Refactor or organize your code to make it more readable and re-usable.
Repeat the steps 1-5 for new behavior: Repeat the steps to implement more behaviors in your application.
Context: Login page Event: Enter username and password and hit Login button. Outcome: I am logged into the user dashboard page.
|Definition||It is a development technique that focus on the implementation of a feature.||It is a development technique that focuses on the system's behavior.|
|Philosophy||It is development practice.||It is team methodology.|
|Participants||Developer||Developers, Customers, QAs|
|Main Focus||Unit testing||Understanding requirements|
|Language||Programming language||Simple English|
|Aim||Reduce bugs in implementation||Reduce bugs in behavior of the system.|
If you landed on this blog without understanding software design and modelling tools, you might want to stop it here and read this post first.
There is no right answer. Some developers might argue TDD is better than BDD, however, it depends on the person, the project, team lead and methodology. TDD gives you high code coverage 2 whereas BDD is better in finding the workflow bugs.
Test cases: In software engineering, a test case is a specification of the inputs, execution conditions, testing procedure, and expected results that define a single test to be executed to achieve a particular software testing objective, such as to exercise a particular program path or to verify compliance with a specific requirement. ↩
Code coverage: In computer science, test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. ↩
TDD: Beck, Kent. Test-driven development: by example. Addison-Wesley Professional, 2003.↩