Writing tests at an early-stage startup is always heatedly debated. If a function has one call, adding a unit test doubles the number of calls, this not only doubles the current work but even slows down future code changes 2X! Further, if the code is not finalized, it is legitimate to ask why even bother writing test code. Here’s a better way to write tests
Always write tests along the axis of minimum future code change. For example, test your REST/GraphQL API, or CLI interface. Not only such code mutates slower but any test-breaking changes here are the most devastating ones. Further, once an all-encompassing test has been written, someone can come in and easily test for more cases. So, this sets up the basis for more future testing of the code.
Always write tests along the axis of minimum future code change.
Some software engineers would immediately out that these are integration tests and not unit tests. And that’s correct. I would even claim that an early-stage startup needs integration tests more than unit tests. Unless you are writing some very specific algorithms, unit tests are usually a waste of time and cost even more time in terms of maintenance in the future.
The integration tests, however, are a coded contract between two engineers, one who is writing the test and one who is modifying that code in the future. It might be the same person 6 months apart!