Is TDD dead?

Last updated May 5, 2024 Published Dec 29, 2015

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 Laravel, a very popular framework for web artisans what they say 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

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 at the ZF 2 website. By now we have two great frameworks that have a huge preoccupation in 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 better 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.” (

The key point

The nature of any test is to guarantee that something 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 it will 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 Heinemer shared their knowledge about this topic and you can find it here I do recommend listening to it is rich material and if you want more you can find the video on YouTube as well.