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.

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.