Unit testing is always a hot topic on every project. Usually in the form of, “Why should I write unit tests?” or “Do we have enough code coverage?”
This is a not an implication of anyone that I’ve worked with. Lots of people can write code, but writing unit tests is definitely a skill that takes awhile to learn. So if I come across people who don’t know how to write unit tests, I don’t get too bent out of shape because it’s takes time to get good at it.
Let’s go back to the original question — Why should I write unit tests?
How many of you have ever had to debug, maintain, or replace legacy software? I’m in the process of doing that right now. Now not all of the code that we’re replacing is bad, and some of it is still useful. The problem is that we can’t change any of it because we don’t know what our changes will break. That’s because we don’t know what the intentions of the original developers were, and we have no way of verifying whether our changes were successful (what is the acceptance criteria?). As a result, we end up having to rewrite code that otherwise might be perfectly good code because we have to make some minor change to it. Since we can’t modify it safely, we have to rewrite the code and everything that depends on it.
Legacy software is the obvious example. Let’s think about your own code.
On my project, there are 15 developers. 15 developers is a lot of people, and we’re stepping on each other toes all the time. Sure, I can write code and just step through it in the debugger and verify that it’s working, but what happens when someone writes code tomorrow that will break my code? How will they know that they broke it, and how will I know that they broke it? Heck, I break my own code all the time, how is someone else supposed to not break it?
Unit tests take time to write, but they will usually save time in the end. In many cases, you’ll find bugs in your code before it gets to QA, so QA doesn’t have to spend time testing it, writing up the bug, retesting it. Then when you have to change your code later on (or if someone else has to change it), the unit tests can tell you if you broke something, saving more QA time. Unit testing also makes you really think about your code and all of the possible edge cases. Sometimes it’s really hard (or impossible) to recreate an edge case when testing through the app and it’s much easier to recreate it in a unit test. Remember, if your code allows for a certain edge case to happen, you should write unit tests around it even if you can’t recreate that edge case when running your application. Just because you can’t do it now doesn’t mean that someone won’t try and use your code to do it later.
How many projects have you been on where you’ve had to make a big change just before the app when into production or while the app was in production? I’ve had to do this many times. Unit tests probably won’t catch everything that can go wrong in this situation, but it sure is nice being able to run 2000 tests to see what I might have broke.
The important thing to remember is that we should be writing software that is going to last as long as possible. This is really hard to keep in mind when you have a deadline looming, or you’re trying to figure out a particular problem.
Nothing lasts forever – business requirements change, programming languages change, development teams change, everything changes. But it’s my responsibility to write software that will last as long as possible. I want my software to get replaced because changes in technology or the business environment allowed them to write something much better than what I wrote. I don’t want them to replace my software because they couldn’t maintain it.