Test-driven development commonly known as TDD is a testing development technique which is based on writing tests before writing the implementation details. TDD practitioners claim that this technique improves not only the code quality but also boosts developers’ mood while writing code. This increase of mood comes from the psychological fact of seeing things working. On the contrary, if you put off writing tests, doing so later becomes a painful chore.
On the other hand, this technique forces you to have fast feedback, since you have to create tests before introducing any new change, so you can deliver value and go to production quickly, and as a result, TDD is highly recommended in combination with other Agile techniques.
TDD can be also combined with other techniques like pair programming, and that combination is called Ping Pong Programming: one developer writes a red test and the other writes the code that makes it pass, then they swap. This is a pairing style layered on top of the Red, Green, Refactor cycle, not another name for it.
ATDD (Acceptance Test Driven Development) is a variant of TDD and is focused on starting testing from the user’s point of view. Testing frameworks like Cucumber are commonly used for these kinds of tests. It is closely related to Behaviour Driven Development (BDD), which shares much of the same tooling.
Key Factors for Using TDD
These are some takeaways from The Three Laws of TDD by Uncle Bob.
- Produces documentation. Tests are examples of how to use the code you write.
- Decouples the code. You will write testable code and as a result you will have to decouple your code to make it testable.
- You make sure your system works.
“Reasons for not Using TDD”
- We have to go fast because maybe we have deadlines, but this means you will pay for the shortcuts later on (and with interest!).
- We want to simply solve the problem and leave a mess behind us. We probably won’t go back and clean it up.
As you can assume, these reasons are not really good reasons for not using TDD, and they will result in future headaches and fear of refactoring the code because we might break the existing code and there is no test suite that ensures that the changes are not breaking the original business logic.
Getting Started
You can start using TDD by following the next steps:
- Write a red test that specifies a particular feature, and watch it fail.
- Write the minimum business logic that makes the test pass.
- Refactor the business logic applying architectural patterns, SOLID principles, DRY…