I think testing is an important part of product development. However, when you're early on with no customers, it sometimes feels like a waste of time to invest in it.
So I'd like to ask you: when do you start adding tests to your product?
Personally, I think the right time to do it is when you have a few customers. Any earlier and it seems premature, especially because you might pivot and rewrite your application. Any later and you might be playing with fire.
Of course, this also depends on the scope of your application and how easy it is for you to QA it. I'm curious to hear how you handle it.
If you break tests down to it's core essence, test help with:
verifying features work as expected, so when you or a different dev changes code, then we can know if existing functionality has been broken
Of course this comes with a cost, because now you're having to write more code for each functionality that you're trying to ship.
At the early stage of a product, there's so much uncertainty, i.e. will your product even be alive in a month's time
In the beginning if you're a team of one dev and the feature surface area is minimal, I don't see what benefit automated tests give if it's getting in the way of shipping something sooner
Plan is to not add tests.
I start adding them during MVP development, for the most critical parts of the application. I don't shoot for 100% coverage (or any specific percent of coverage), but I do some minimal testing on parts that I can't allow to fail or are hard to test manually (eg. for Amethyst Platform, I test the conversion of the amethyst.yaml configuration file to Kubernetes resources, so that I also make sure that I report meaningful error messages).
Hi Richard,
I second your arguments.
Writing tests does not add any value in the early stages with a small amount of customers. But when the customer base grows, and you realize that you are building a technology that delivers a lot of value per request, then it is probably time to ensure that technology works as expected automatically.