I'm a software engineer by trade and so I try to follow the best practices every time I need to work on some code. One thing that bothers me is when should I write unit tests for code that may change later on?
What if the feature is a beta user interface? What if you've manually tested it and it works fine? How do you justify to your customers that you've checked everything but haven't written automated tests for it?
I've come to answer these in the most pragmatic way possible: through the order of importance. As a founder, I need to worry about other issues too, like user feedback, product-market fit, scalability, marketing, sales, etc... There's no way I can spend time writing tests all day when there's money to make.
What I've learned to do is write unit tests for critical path functionality only. Signup, onboarding, end-user product functionality. Things that matter to the business immediately.
I'm not going to write `setUser(mockUser); assert(instance.user).toBe(mockUser);` and I'm not going to endlessly make Jest snapshots for every React component. What I will write is a mixture of end-to-end testing and unit testing — ones where resiliency matters.
For example: insertion of a credit card and a mock call to Stripe. If that doesn't work, I'm not making money.
Another example: Unit test on headless browsers that ChipBot (my startup) can open in a wide array of browser environments.
For customers who question tests? You answer that you test everything. You most likely already manually test all your products. Adding the critical path unit tests only strengthens your foundation.
Finally, often times you will be throwing away your own unit tests for new features. I've refactored 3 or 4 times for my MVP and I've avoided premature unit tests. Writing quality tests will become a priority when your product matures.
In the beginning, there's no time to rigorously follow TDD or to hit 80% coverage. You have to test based on what matters most in the beginning.
Your MVP requires getting user feedback ASAP.