The unit testing trap for early founders

We recently started working on Sabil. A core part of the product is accurate device fingerprinting.

In our early releases, we shipped a bug. So we decided we needed automated testing so that any code change can be run against these tests, and we'll know if things break immediately.

That was all good, and it worked perfectly. But as we kept making changes and failing the tests, we added new tests for edge cases. So the tests are enormous now, and I can see them growing even further.

Here's what I learned:

1. Despite the extra work, writing unit tests for the core part of your business is beneficial.
2. You can quickly go down a rabbit hole with testing and adding more tests, then improving the quality of the tests, and so on.

My question for the community is, what are some good rules you've developed around unit testing?