What's your view on tests before launching?
Question for all technical indie hackers out there: I'm still writing my MVP, launching in a couple months (4 since first line of code).
I'm at point where I hit lots of regressions and I go back to rewrite the broken code.
If it was for my company or clients, I would always test. Both e2e and unit. But as I want to launch asap, writing tests could (in the short term) definitely slow me down.
So I can:
- test now, launch later
- test when launched, pausing features for a while
tests?
No but seriously. I just do manual testing my self. Once my services will grow I will introduce automatic tests.
I would recommend going alpha, beta stage first (specifically mention this for clients). And then be patient with support calls as you gonna get it a lot. But this way your clients/users will give you more relevant feedback than tests. Of course, having your app crashing isn't a way to give for testing.
I don't test and never have (other than manually). I actually really need to start doing that soon.. but I'd still avoid for an MVP that's changing rapidly.
+1, exactly my response too.
What would make automated testing easy? I just don't want to get started on it because it feels like it is quite a steep learning curve....
If you're trying to launch something quick you can skimp a bit on tests, especially if you're in the phase where you're rapidly changing direction. TDD and unit testing are much more effective when you have a clear vision of the end product, and that vision isn't going to change much. if you're still in the discovery phase then you'll waste a lot of time fixing tests, which isn't all that productive. I do however like to write tests around mission critical items here, things that need to absolutely work 100% from day one.
That said, I'd always budget time to go back and write tests once I'm comfortable with the initial MVP and it's in a stable state. Don't fall into the trap of constantly building new features and pushing off tests. That will work for a while, but it's a recipe for headaches down the road. If you're writing good code to begin with, going back in and having unit tests shouldn't be a huge undertaking, especially if you've truly got an MVP that's not too dense on features.
I always write unit tests irrespective of MVP or an actual product. The reason I follow is that generally, my UTs become my first client for the code. E2E, and other tests I generally skip during MVPs.
I do a mix:
Start without tests. Just write code and move your application forward.
Two scenarios where I write tests:
When you reach a specific problem that is tricky or that you have to think to know when the application is behaving right or wrong, write a test for that. This has only applied to me on hard algorithmic problems (bitcoin derivatives trading platform).
When you encounter a bug on a previously untested part of your application, write a test for it and then fix the bug.
Working on an MVP requires speed and flexibility (you are still not sure what you're building). If you lock yourself down with too many tests you will probably soon be writing tests that work in code but not on the market.
Hope this helps!
@pablof7z
How much do you trust yourself to write a stable application without tests? Are the bugs you’re experiencing things that would bring the system down or minor issues?
Think about those questions then you can decide 🙂