And to be honest, I don’t always unit test backend code these days either.
I have spent years educating myself in the art of unit testing. In my career, I have probably written thousands of unit tests.
Every time I pushed code, hundreds of green lines flowed through my terminal. And sometimes they turned red. And my face turned red also because then I had to fix them.
Most of the time they turned red was because I had changed the production code and forgot to update the unit test accordingly. I very rarely discovered a regression.
Unit tests are not free
Unit tests are code that must be maintained like any other code I write. I double or triple the amount of code when I write unit tests. Unit tests come with a cost so they better be worth it.
I am just as careful about not introducing too many tests as I am careful about adding too many dependencies or writing more code than is necessary.
One problem with unit tests is that you can only test what you know.
But bugs comes from what you don’t know. In my experience, most bugs in production are bugs that you could never have thought about in your wildest dreams.
Users click in places that you never thought they would click. And they write texts in input fields that you never thought was possible.
Backend systems you don’t have control over give incomplete or wrong data that generates the weirdest behavior in your app.
None of those things are possible to discover in unit tests.
I have come to peace with my apps being broken and that I will forever have bugs. That’s the nature of software development. What I can do is fixing the bugs quickly when I find them.
There are other methods to ensure quality
People who advocate unit testing says it’s a method to get better code quality. They say it makes the code more decoupled which is good coding practice.
I have found that pair programming, code reviews, and discussions are much better ways to achieve high code quality. It is much more valuable to spend my time in those activities than writing and maintaining unit tests.
Write tests to document your code?
Many people point out that one strong argument for writing tests is that it helps in documenting the code. That is true. It is especially important in projects where every dev works remotely.
But I work on teams where all members are on site. We talk very closely together. We pair program. When new devs join the team we talk to each other about the new code. Unit testing as documentation is not so strong argument for me.
Sometimes I do write unit tests I have to admit.
When working with data transformations it can actually speed up my development when I do TDD because it shortens the feedback loop.
Also, parts of my code base that is super complicated and prone to bugs is often worth creating a few unit tests around.
I carefully consider where to use unit tests just as I do with any other tool or method I use.
My point with this article is not to tell you to never write unit tests – there are many examples where unit tests are valuable.
My point is that you shouldn’t feel bad if you make an informed decision that unit tests are not a priority in your project. There are cases where it is fine to not write unit tests.