Why Unit Tests Don’t Really Help You
The point of software is to solve a problem, that could be your own problem or someone else’s. What unit tests are supposed to do is to help you validate that your functions are working individually and hopefully since they are easy to test and they compose well they will tell you if your system is working together as a whole.
Unfortunately in practice this doesn’t really pan out. Usually the majority of functions that get written in the majority of web applications are very simple, so simple in fact that unit testing them seems like a waste of time so they just don’t get tested or the tests tell you what you already know from looking at the code.
If solving problems is what you’re after you really want to be able to ask, is my system working the way I want it to, or more specifically, a few questions like:
- Can people log in?
- Can people log out?
- Can people sign up?
- Is the stripe integration working?
- Are my API endpoints working?
- Can people manage x, y, and z objects?
The main problem with unit testing is that it doesn’t answer those and any other important high level questions. Luckily there’s another method that gets railed on quite a bit…
End to end testing
There’s a blog post by a google engineer (who is one out of a few thousand engineers at google) about why they moved away from end to end tests, here’s what a common conclusion about end to end testing winds up looking like

I think this common wisdom requires a second look based on where it’s coming from. Usually this type of thinking about “flaky tests” comes from large teams where things are changing very quickly and where the tests aren’t quite keeping up. But if you are a solo dev or a small team, things probably aren’t changing that quickly and it’s probably better to have a suite of automated end to end tests that run in minutes instead of trying to smoke test just your new feature and assuming that change you made to that shared object or table won’t affect any other feature.
End to end tests, or fully automated browser tests using selenium or something else really shine in small teams and for indie devs. It’s really simple to write a quick end to end test and you get a lot more mileage out of every line of those kinds of tests vs a few hundred unit tests. The trade offs of “it takes a long time to run them” (usually on the order of minutes) vs the nanoseconds it takes to run a few unit tests is a trade off I and I think a lot of other indie hackers and small teams are willing to make.
Conclusion
This all kind of comes back to a strange industry wide obsession with trying to emulate the largest internet scale companies in your tiny product. Software itself may scale pretty well, but the techniques and tools used for very large software and teams don’t. When you see another blog post on hacker news talking about how a large team at a large company solves a problem don’t assume it will solve your problem.
