TDD: A magic trick, a curse, or just a helpful process?
Let’s discuss test-driven development. Some say it’s a waste of time. Others liken it to a magic spell that will instantly find bugs in their code. So, what is the truth? We take a look at just some of the opinions in the vast ocean of TDD debate. What do you think?
Test-driven development (TDD) is a divisive topic among programmers. On the surface, the definition sounds quite standard. From its Wikipedia entry:
TDD is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.
Kent Beck has been credited with developing the technique in 2003, although it is based off of “extreme programming” related concepts that started in 1999.
A quick search on the concept shows opinions ranging from dogmatic praising to cautionary tales preaching avoidance. Does the truth fall somewhere in the middle?
Robert C. Martin (also known as Uncle Bob) has laid down three simple rules for implementation:
The three rules
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
SEE ALSO: Top 5 IDEs and text editors for Kotlin
Asking the academics
Java trainer Ted Young recently published a blog entry tackling the concept of TDD and whether or not to adopt its practices titled “Looking at TDD: An Academic Survey“. In it, he explores the opinion that several bloggers represent, that TDD is not worth using. However, Young goes straight to the source and looks at a survey of academic research testing the quality of TDD and determines its worth using the data and not opinion.
His research came to the conclusion that TDD is worth adopting. Young triumphantly Tweeted, “Even the ‘low relevance’ (but still ‘high rigor’) studies indicate that you are pretty likely to do better, and possibly no difference, so why not do TDD?”
In 2008, Microsoft released a research paper titled “Realizing quality improvement through test driven development: results and experiences of four industrial teams“. From the abstract of this paper: “Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.” (Note: this research is already a decade old, so take these numbers with a grain of salt.)
No magic bullet
Uncle Bob revisited test-driven development on The Clean Code Blog in 2017. He hammers home the fact that it isn’t TDD that makes your code better: it’s just you and your code. Bad code is bad code, no matter how it came to be and the same is true for excellent code. Uncle Bob leaves us with this wisdom: “Is is only programmers, not TDD, that can do harm to designs and architectures.”
The debate continues
The above sources is just a toe-dip into the fast-moving river. For those who are more interested in delving deeper into the debate, there is a series of conversations (available in video, audio, and even translated into Japanese) between Kent Beck, Martin Fowler, and David Heinemeir Hansson called “Is TDD Dead?”
What do you think? We encourage you to scour your own data, read academic articles, and look at your own code. Do you use TDD?