Opinion: When should I write unit tests?

Photo by Ruben Mishchuk on Unsplash

None of us want our projects to get derailed by broken code, but the reality is many of us are working on different things. And each one of us will see different value on writing unit tests. Never-the-less this still is a controversial subject in some circles, I have seen a variety of differing opinions.

The purpose of this post is to take a look at unit testing from a cost-benefit perspective. I’m not saying this is the way to do unit testing. The correct answer is always, do what works.

First, let’s take a look at some of the prevailing opinions out there on unit testing.

Only the Sith deal in absolutes. If someone says all unit testing is a waste of time, you’re talking to someone who has fallen to the dark side. Be wary.

Code often gets too atomic.

This I think is a more reasonable approach to things than the former two.

Well… Where are you in the Product Life Cycle?

Personally, I think it makes sense to ask yourself the question, “Where am I in the Product Life Cycle?”. This will help you see the bigger picture and decide whether it’s worth writing unit tests and all other tests in general.

Image by Malakooti, B. (2013). Operations and Production Systems with Multiple Objectives. John Wiley & Sons. CC BY-SA 4.0

If you’re in start up mode, doing proof of concepts, are writing tests really going to add value? Probably not. You probably haven’t even finalized core functionality at this point. So why test it?

There’s the argument that TDD makes sense and unit tests are good requirements to test against. But even here I’d say your requirements are probably changing too quickly.

Okay. Enter testing. At this point the cost of code failure and potential problems begins to outweigh the cost of testing.

You should be developing a testing strategy at this point that includes other types of tests as well. This is when I think it makes sense to begin unit testing. You know what the core functionality is at this point, from here on out everything else is ramping up and adding features.

In this stage, the cost of test coverage is clearly less than the potential risk of downtime. Test the sh*t out of your software.

Writing new tests at this point is useless. It’s just a matter of time before the project you’re working on gets retired. Even maintaining tests is costly in this phase. You probably have a replacement piece of software in mind and a good chunk of the software has already been battle-hardened by users.

So if you have no major development planned, and a test or two fails as long as users aren’t complaining… who cares?

Ehhh you should. As the person charged with maintaining an old system, you need to care. At this point unit tests can act as kind of a canary in the coal mine. If a unit test is failing. You should at a minimum understand why it is failing. Tests don’t fail in isolation, something has changed to induce a failure. Investigate it.

Other thoughts

There is no light switch for when you need to be in test writing mode, it’s more of a dimmer. You need to ramp up on unit tests. This is why I like frameworks like Jest so much. They do not get in the way and can easily be added at any point to a project.

If you’re only using one type of test. You’re doing it wrong.

Unit tests are super valuable. But if you’re only writing unit tests, and arguing about what type of tests are better… you’re kind of missing the point of testing. Unit tests are a part of overall testing strategy.

This article is about when, but what should you actually unit test? Henrik has a good answer to that:

Okay so you’re convinced (maybe?) that you should implement some sort of unit testing. MPJ has a great guide on how:

Web/Mobile Developer