For whatever reason, I have seen the topic of unit tests appear in my daily reading frequently the past few days. Because I am in that kind of mood, I wanted to rant on unit testing. First, let’s look at some of the articles that caught my attention. One article talks more about the psychology of unit testing and starts with an interesting paragraph:
The philosophy of economics, and psychology, and morality, all overlap in studies that show how people will readily abandon moral responsibilities if they are given ways to avoid the stigma of doing so. This leads me to feel more justified in my belief that programmers do a poorer job of reading, understanding, and implementing a specification when someone else has the responsibility of verification.
To put this more simply, if you do not have the responsibility to test your own code, it will be of lesser quality. I have seen this in practice, and I would have to agree. Code that does not have unit tests almost always has more defects than code that is unit tested. So, why do programmers avoid writing unit tests? There are plenty of excuses, and the second article has a good list of them. From that post comes my favorite excuse:
It’s not my job to test code – I don’t know at what stage a software developer decides that he can just throw code over the wall. If your job title was simple Coder than maybe there’s an excuse. But as your job is to develop working software, you need to be able to say that your code is functional.
Read that last sentence again, “your job is to develop working software, you need to be able to say that your code is functional.” As a software developer, can you really say that you have done your job without providing unit tests?
If you are not writing unit tests, you are not providing any proof that your code actually works. You are doing yourself a disservice and any developer that maintains your code will complain at length about it.
Another classic excuse is that it takes too much time to write unit tests or there is not enough time in the schedule to write the tests. The schedule excuse appears a lot as project scheduling is never as good as we would like. When I first started writing unit tests ages ago, I believed that the schedule excuse was OK. As I continued through my career, I realized that there were more defects in my code that did not have unit tests. I also realized that fixing the defects was harder if there were not unit tests. I know this is anecdotal evidence, but when so many people in our industry say the same things, the anecdotal evidence becomes more than just coincidence.
An interesting side benefit of creating testable code is that the design typically ends up easier to deal with. I think this has to do with the fact that your code becomes more component-oriented. You need to break many of the dependencies that quick-and-dirty coding tends to introduce. If your code is hard to test, it could point to design flaws or at least unnecessary complexities.
So, if you are a software developer, even if you are just learning the trade, test your code. It is your job to show that your software is working. Quit complaining, get over it and start writing unit tests.