How much test coverage for an MVP? (Day 63)
Image from watirmelon.blog
Do you write tests for your MVP?
My personal answer is: "no" for the frontend, and "yes" for the backend. While developing backend APIs, my favorite tool is Paw, it feels "lighter" than Postman, and use the Playground when writing GraphQL. Once the development is done, however, it is way easier to test the entire "suite" with unit tests.
By default, developers want to use typescript. But TS is designed for large applications, it is overkill in MVP stage, IMHO. Unit tests, integration tests, regression tests are all cool when there is a team of engineers. As bootstrappers with limited resources and the product iterating fast, writing test cases usually stays in the backlog. For form inputs, I'd use schema validations and also use schema to make sure we have all the valid data for making service calls.
Once the MVP is launched, however, it is important to have some basic test scripts for smoke tests and regression tests--making sure auth works, pages are loading, images are showing, and transactions are going through, etc.
What is your philosophy on test coverages during the MVP phase, fellow IHers?
I'd only test what's absolutely necessary for you to maintain trust with your users, and no more than that. For most apps I'd guess that means zero tests.
The reason is that you're no longer a developer, you're a founder. That means you're responsible for every job in the company, not just the software dev. And since you don't have enough time to do an amazing job at everything, you have to cut some things.
The most common failure mode is going too deep on the jobs you're familiar with and ignoring the other vital parts of your business. For developers, that's spending too much time coding and not enough time on marketing, sales, design, strategy, etc. When you don't even know if your business will work or your product makes any sense, now is probably not the time to be writing lots of tests.
I think it very much depends on what your app does. If it updates or in any way manages data created by your users, then you need to be religious about testing, regardless of the fact that it's an early stage MVP. A bug that deletes or corrupts important data created by a user is unforgivable.
If your MVP doesn't manipulate or manage user data then testing is of low importance.
I wouldn't necessarily test everything on the back-end early on, especially if your app is frequently changing.
I would test everything related to payments and user privacy.
I don't do any tests during the MVP stage. My MVPs are just a single page that demonstrates the one thing the user(s) were asking for. Even if the tests where scaffolded into my project frame work I don't use it just yet.
If it's validated and/or gained traction then I build it out the right way. At that point I'd make sure to cover my butt (especially if someone was paying for it).
My philosophy is spend 99.9% of your time finding product market fit. If you find it then you'll eventually get to a place where you can 'do it right' or maybe even hire a team if that's the goal.