Are Unit Tests a Waste of Your Time?

Unit tests are just a waste of time: you'll always end up spending more effort maintaining them than writing code

― someone, at some point in your career, probably

I've heard it dozens of times, in more places than I can remember. Usually frontend devs are more inclined to think so than their backend counterparts, and for a good reason: there's still room for improvement when it comes to frontend unit testing.

I've been lucky enough to start a fair amount of greenfield projects in the past years, both large and small, and looking back, I feel like writing tests had (or would have) always saved time. But, it took me quite a while to truly see the benefits and change my headfirst habits. I imagine there are other skeptics out there, so, here's what I'd tell my younger self.

• There's no such thing as "not enough time to write unit tests"
• You'll never write them "later", you need discipline to do so, and if you don't have it as you code, you'll certainly won't have it as the project gets larger
• No project is small enough not to unit test
• In retrospect, for anything more than 5 lines of code, it will always be more expensive to manually test your code
• You'll find that as you make your code testable, you also increase its intrinsic quality, to the point that testable code will sort of become a synonym for clean code.
• Remember when you had that one awkward bug and it took days only to reproduce it? Software systems are complex and require the perfect alignment of many moving parts, some of them not under your control. If something goes wrong only in a rare scenario when a third party (like, Google or Stripe API) returns something unexpected, it becomes almost impossible to debug. Because unit tests allow you to control the state of your application in great detail, reproducing such an issue becomes much easier.

Unit testing is not some extra or nice-to-have thing, it's a mandatory step in the software development process. As an engineering team, you can decide to skip it, but it will bite you back and waste many good hours.

In the end, what are your other options?

1. You don't test at all. Needless to say, the resulting product will be an unusable crap. You'll have to fix it solely based on user feedback, and this will lead to unfathomable costs. You will fail, your team will fail, you'll have to find another job.

2. You let others do the manual testing. Soon enough you'll discover that issues that you'd have otherwise caught fairly quickly, will keep bouncing back and forward between you and testers.

This is an improvement, at least your users don't do the testing anymore, still, the constant ping-pong is time-consuming, plus with each iteration you'll have to restart the whole process. More $$ down the drain.

3. You manually test your code throughout before passing it down the line. This is probably the most common scenario out there, or at least I hope it is.

You'd be inclined to think it's enough, as a developer, you'd know where to look and fix things quickly. However, considering how complex state can become and how tendinous triggering all the required conditions to replicate an issue is: you'll end up spending a serious amount of time, not coding per se, but clicking and following user paths.

Back to out initial statement, it's true, either way you'd take it, unit testing is time-consuming, especially if you have a poorly designed codebase. But, you'll have to test your code anyhow, the only choice is, waste your time doing it manually or invest some effort in learning how to properly write unit tests, and profit later.