Table of contents
Is TDD dead?
The content here is under the Attribution 4.0 International (CC BY 4.0) license
Recently I’ve heard about the death of TDD, but is it true? Some argue that TDD is dead and those who had used it in the past are not using it anymore. Frequently I tried to follow all the rules of TDD when I’m coding but I have to confess, it is not easy. Though I do write unit tests (and functional as well), sometimes without following the gold circle (Write the test first see it failing and then make it pass).
How about the frameworks?
The first thing I’d like to understand is why frameworks are worried about testing. Let’s see what Laravel, a very popular framework for web artisans, says about testing:
“Laravel is built with testing in mind. In fact, support for testing with PHPUnit is included out of the box” (Laravel’s website)
While I’m writing this post, the latest version of Laravel is 5.2, and as we can see, Laravel has many facilities to use TDD. Find more information on the official website: https://laravel.com/docs/5.2/testing.
The next chosen one is Zend Framework 2.
“A solid unit test suite is essential for ongoing development in large projects, especially those with many people involved. Going back and manually testing every individual component of an application after every change is impractical. Your unit tests will help alleviate that by automatically testing your application’s components and alerting you when something is not working the same way it was when you wrote your tests.” (ZF 2 official website)
You can also see more details on the ZF 2 website. By now, we have two great frameworks that have a huge preoccupation with TDD and testing. Now I ask you: Is TDD dead? Are you not convinced yet? Symfony’s documentation goes further, saying we must write unit tests and functional tests to improve the quality of code:
“Whenever you write a new line of code, you also potentially add new bugs. To build better and more reliable applications, you should test your code using both functional and unit tests.” (http://symfony.com/doc/current/book/testing.html)
The key point
The nature of any test is to guarantee that something is still working after a change or, even better, when we are driven by tests, where it can improve how we build things. Also, we can point out the flexibility it brings when we need to test the entire application. Imagine you have an application with twenty modules and 200 or even more functionalities. After a change, how can you guarantee that you haven’t broken anything? Of course, you could test every piece manually, but think again: how long will it take?
It’s true also that TDD philosophy says we must write the test FIRST, which means we should write the test and then the source code. Sometimes we don’t know how the things could fit together and how can we start with the test. I’m not a TDD nazi but sometimes and in some cases, we can break the rule and write the source code first and then give it coverage using tests. Choosing this path we can lose some goodness of TDD but it is your choice.
The 2014 debate
The question in the title is not rhetorical, and the answer depends on which question is being asked. In 2014 David Heinemeier Hansson argued at RailsConf that test-driven development damages the design of a system when it is applied everywhere, because the production code ends up shaped around what the tests find easy to reach. Kent Beck and Martin Fowler responded, and the three of them recorded a short series of conversations published as the recorded conversations between Beck, Fowler and Hansson.
| Who | The claim | What the claim is actually about |
|---|---|---|
| David Heinemeier Hansson | TDD applied everywhere causes test-induced design damage | Its scope, not its value, he still writes tests |
| Kent Beck | TDD is a design tool, and only one of them | Which design problems TDD is good at, and which need another tool |
| Martin Fowler | Much of the disagreement is about whether to mock, and how much design should follow the tests | The economics of the technique rather than its validity |
Read that way, the debate was never about whether to write tests. It is about where the tests sit in the loop, and whether the design follows the test or the tests follow the design. That distinction is what decides whether TDD helps a codebase or damages it.
Going further
Martin Fowler, Kent Beck, and David Heinemeier Hansson shared their knowledge about this topic, and you can find it here. I do recommend listening to it. It is rich material, and if you want more, you can find the video on YouTube as well.
Emily Bache also shared some thoughts on the matter and went further, elaborating on the stages of test-driven development and the fuss about it being a dead practice.