These are the words from software guru Jim Coplien, who penned some of the most influential C++ books in the 90’s. The exact quote is:
TDD done strictly from the YAGNI principle leads to an architectural meltdown around iteration three.
It’s very refreshing to see the anti-TDD movement gather up some momentum, and I particularly enjoyed the discussion between Jim and Bob Martin, the notorious TDD extremist who thinks that every software developer who doesn’t TDD every single line of code she writes is unprofessional.
Jim and Bob had an interesting debate recently, which you can find transcribed at InfoQ. I have to give credit to Jim for his civility as he faces Bob, whose arguments never suffered much tolerance for people who don’t agree with his views.
I have been bothered by TDD for a long time now, and my skepticism and even opposition to some of its effects can be found either in the presentation I made with Alexandru at InfoQ called Designing for Testability or more recently, in the book I co-authored with Hani Suleiman.
Having said that, don’t expect me to become Bob Martin’s counterpart. I certainly don’t believe you should never use TDD, but I do believe that the benefits associated to TDD are vastly exaggerated and that the software community needs to keep in mind that TDD is just a tool, and that as a tool, it’s not adapted to all situations. I especially dislike the efforts of TDD extremists who are trying to make developers feel bad whenever they don’t use TDD, or lead them to think that something is wrong with the way they write their software.
If anything, it seems to me that most of these TDD extremists have been talking to conferences for too long and have become way too comfortable writing Stack classes or code that calculates the score of a bowling game. These toy applications are easy and they make TDD shine, but don’t be surprised if your audience leaves the room scratching their heads and wondering how they can apply it to their real job. Good luck using TDD to write a mobile application or to interface with a mainframe that needs to handle hundreds of thousands of two-phase commit transactions spreading over three continents while thread contention remains to a minimum.
I don’t know about you, but I’m getting a bit tired of fear mongering in the software community, whether it comes from TDD fanatics or from people who claim they wouldn’t hire someone who doesn’t use a Mac for development.
When it comes to testing, I live by the following rules of thumb:
- “Tests first” or “tests last” is unimportant as long as there are tests.
- Try to think about testing as early as possible in your development process.
- Don’t let one liners contradict your experience. For example, don’t listen to people who tell you to write “the simplest possible thing that could possibly work”, also known as YAGNI. If your experience tells you you’re going to need this extra class in the future even if it’s not needed right now, follow your judgment and add it now.
- Keep in mind that functional tests are the only tests that really matter to your users. Unit tests are just a convenience for you, the developer. A luxury. If you have time to write unit tests, great: they will save you time down the road when you need to track bugs. But if you don’t, make sure that your functional tests cover what your users expect from your product.
- Don’t feel bad if you are not doing Test-Driven Development. There are a lot of factors that make this practice a bad fit for a lot of projects and developer personalities (aspects which are very often never mentioned by TDD extremists).
Don’t let extremists make testing a chore, because it can truly be one of the most rewarding aspects of our profession if you exercise it with judgment.