Testing: Differences between TDD, ATDD and BDD
Testing, while at times decisive (the client isn’t paying for us to test!) is crucial to successful project completion. Unit testing, left to a developer, is often not enough.
A test strategy should be a carefully considered implementation with a balance between time spent and benefits received.
This particular guide is going to run through TDD, ATDD and BDD. So let us dig in!
Test-Driven Development (TDD)
Test driven development revolves around using Unit Tests to test code, decoupling dependencies from the code (using techniques such as dependency injection).
Tests should be written before the code is written.
The TDD process involves writing Unit Tests before code is written. For the developer this means you must know the behaviour of the code before any particular algorithm is written to solve a problem. TDD asserts some conditions that may be the output of some particular function.
It also means that you need to write enough tests to cover al the paths through the code in question, this means we need to make sure that our code coverage is a good percentage of all of the lines of code we write.
The TDD process does not stop a developer refactoring code and maximising the efficiency of code that will go into production (far from it). As part of the usual code review process TDD also fits satisfactorily, and since you are arguably you are reviewing your own code as you go (with a good quality test making it clear whether or not your code is of suitable quality) you can make a case that TDD is likely to provide even better code than that produces without the methodology in place.
There are several great advantages in using TDD:
- Should reduce the maintenance burden
- Bugs should be readily apparent, and feedback for fixing them should be near-immediate
- Code should be testable when written
- As developers get used to TDD, productivity should increase
- Code should be easy to understand, as it is driven by the tests
Behavior-Driven Development (BDD)
BDD is a derivation of TDD, but the tests are mainly based on systems behaviour.
That is, while TDD asserts some conditions BDD can be written in common language (normal written English) using real-time examples of actual requirements to explain the behaviour of the system.
A Given-When-Then approach is typically used for writing test cases.
Given: a certain scenario
When: an action takes place
Then: This should be the output
Given an iOS login screen:
Given: The user has not entered their password on the form
When: The submit button is pressed
Then: A failed validation message should be displayed
There are several advantages in using BDD:
- In defining the behavior of software you are moving to a higher level of abstraction (so more job functions can write tests)
- Enhances communication between developers, testers and product owners
- Acceptance criteria can be established prior to development
Acceptance Test Driven Development (ATDD)
ATDD tests are written from the user’s perspective. It is similar in nature to BDD, however ATDD focusses on the code meeting the requirements of the software. Like BDD, tests are written in standard English but the focus on writing acceptance — that is ATDD turns BDD into an executable specification (this is the test), and that specification can even be automated.
Due to the nature of ATDD, their formulation requires collaboration between developers, users, product owners and testers.
- Communication across the whole team is a good thing
- Acceptance tests serve as a reminder of the end-point that the software needs to achieve
- Automation of ATDD can reduce feedback time
Testing is important, as good testing methodologies should ensure that software actually (you know) works.
This article has moved through BDD, ATDD and TDD and I hope is useful in formulating your testing strategy as you move through your current and future projects.
As ever, is you have any questions please do get in touch!
Extend your knowledge
- Cucumber supports BDD and is available from their website (HERE)
The Twitter contact:
Any questions? You can get in touch with me HERE