It could very well be the fact that I have four kids that makes me interpret this particular question as coming from the mouths of one of my children. It’s like I have asked developers to eat their broccoli while staring at a three scoop sundae sitting not 6 inches from where they sit.
First off, I’m not a ‘true believer’. I don’t do TDD for every drop of code I write. For instance, if I have a simple property (that is, nothing but storage and retrieval), I won’t start by writing a unit test. This changes the moment that I put any kind of functionality (like validation) into the property. But my starting point for properties is not truly red-green-refactor.
That having been said, my short answer to the question in the title is “yes”. My longer (and less sensitive) answer is ‘Of course you do. Duh! Why would you not want to write unit tests’.
To be honest, if you’re a developer and asking this question, I’m guessing that you don’t understand why you should actually demand that unit tests be written for your code. So let’s go over what the benefits of a good suite of unit tests.
Change != Breaking Changes
Your code is going to change. Maybe not today. Maybe not tomorrow. But some day and for the rest of its life. It’s one of the few givens in programming. But when you do make a change to your code, how do you know whether or not it’s a breaking change. I mean, you’re trying to avoid breaking changes (at least unintentional ones). But how do you KNOW?
The answer is that without unit tests, you don’t. So one reason for writing unit tests is to make sure that when you’re fixing a bug or adding a new feature that you don’t unintentionally introduce problems. This was driving home for me about 8 or 9 years ago. I was working on a project for a commercial application that had about 25-30 people on the team. We were getting close to delivery and we went through a performance sprint. In other words, the sole purpose of the sprint was to find bottlenecks and fix them.
Ask yourself this question. Would you, about two weeks prior to the delivery date of a large project, completely revamp some of the internal functionality? Change how some fundamental functions worked so that performance was improved? If you did, would you be putting your project at risk?
With a complete set of unit tests, we could do this knowing that so long as all of the tests were green when we finished the change, the rest of the application would be unaware of our modifications. Unit tests allowed me to sleep peacefully when the product was eventually released.
Better Interfaces
One of the interesting side effects of unit testing is that you have to be a consumer of your own classes. You have to create and use the methods that you have created. Sometimes that can be an interesting (and humbling) experience. If you find a method awkward to use, odds are that any other developer will have the same feeling.
So fix it. As you’re writing your unit tests, change your methods, change your parameters, make it better. This is part of the refactoring step in TDD. But if you haven’t had to actually use the methods that you created, you’re less likely to see that it’s not easy for someone else to use them.
Built-In Documentation
How many of you write documentation for your code? Yeah, though so. How about putting comments into your code? More, but probably still not that many. What if you could provide any future changer of your code examples of how you expected that your methods would be called?
That’s what unit tests provide.
Again, for every reasonable combination of parameters, you have a method that demonstrates what you expect to go in and what you expect the result to be. It’s not as viewable as a help file, but it beats the heck of the ‘nothing’ that you’re currently doing.
Ultimately, the reason to unit test is not just to find bugs. It’s to allow for the natural evolution of the code you write to continue without you needing to be there. And doing something other than maintaining the code you’ve written is an ideal that we all strive for.