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 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. projects There's no such thing as "not enough time to write unit " tests You'll never write them "later", you need 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 discipline No project is small enough not to unit test In retrospect, for anything more than 5 lines of code, it will be more expensive to manually test your code always 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 ) 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. API Unit testing is not some extra or nice-to-have thing, it's a 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. mandatory In the end, what are your other options? 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. 1. You don't test at all. 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. 2. You let others do the manual testing. 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. This is probably the most common scenario out there, or at least I hope it is. 3. You manually test your code throughout before passing it down the line. 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, , 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. you'll have to test your code anyhow

Google

Stripe

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Are Unit Tests a Waste of Your Time?

Too Long; Didn't Read

Companies Mentioned

Valentin Radu

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Are Unit Tests a Waste of Your Time?

Too Long; Didn't Read

Companies Mentioned

Valentin Radu

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES