Learn to love to write unit tests

When you’re a building a web application with a small team and “moving fast”, unit tests always seem to be the first thing you can set aside for later — don’t do that

I have built a bunch of web apps in my day, and I write server side Django code almost everyday. Looking back over the past 3-4 years, one thing I noticed was that in my personal development process, whether I was building a new feature or fixing a bug, I always left the unit tests till last, and unfortunately sometimes that meant not writing them at all. Then today I came across this Quora question which links to this Hacker New discussion indicating Pinterest wasn’t writing unit tests for a while (I am assuming they are now …)

Let’s face it, writing unit tests sucks. It’s boring, you arn’t really building anything (cool anyways), and when you are very early in the software development process, things change so quickly or the product hasn’t been ironed out yet and they always just break anyways. On top of that, if you are using a database like MongoDB that is not built in to Django (if you are using Django), you can’t use awesome features like fixtures, etc.

As much as they do suck, here are some reason you should ALWAYS write unit tests though:

1. You don’t have to re-learn your code six months after you wrote it: As your code base grows, it gets harder to remember how everything works (obviously). Even though you do not remember writing the code or the unit tests that accompany the code six months ago, I promise you that the minute you look at them, your life brain will start churning. I find that I actually don’t look at view/controller code anymore — I go straight to the unit test. If it is a standard HTTP view, it’s pretty easy to figure out what is going on from there. This saves a lot of time, and hence saves money, which makes your business more profitable.
2. You do not have to teach new employees how shit works: One thing that can be really annoying when you hire someone new is having to answer a bunch of new questions. You should expect some questions, but the more questions you answer, the less work you get done, and the less productive you are. This can make your life frustrating and slow down your company (and maybe even give a competitor the upper hand). In some situations, I have even seen people hesitate to bring on a much needed new hire because it is going to be more work for them (and then everyone loses). Well-written and well-documented unit tests can act as a free introductory course in your codebase, and give you the ability to say “go look at these unit tests and then let me know if you still have questions”. As software engineers, we love to automate away anything to make our lives more efficient. I really love automating away new-hire education.
3. Good Unit Test Coverage Enables Continuous Deployment: The more unit tests there are, the less scary deploying major changes to production are. Continuous deployment is something that I think most start-ups should strive for. I love the idea of pushing everything that passes unit tests directly into users hands via production. From a programmer perspective, it is great to see if your new feature is being adopted, and being faster than your competitors is usually a good thing also. From an organizational perspective, engineers are happier when they do not have to jump through hoops to get shit done. Let’s face it, no one likes to work on features that take six months to get into user’s hands. Unfortunately, if you have a large codebase, unless you are well unit-tested, continuous deployment is almost impossible. The one sure way to not be “scared” you broke something is to see hundreds of unit tests pass before your production servers are restarted.

I realize that nothing in this blog post is amazingly insightful, but I hope after you read it, you might re-think putting off unit testing till you have more time, because chances are, if you’re in our industry, you never will.