Indie dev. Aspiring mathematician and distributed systems enthusiast.
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.
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.