Write tests for the code before project proves viable?
Hey fellow Indie Hackers!
So I've started to work on a project of my own recently and I need to write some backend code - I'm a pretty experienced mobile developer, but the backend part is new to me.
On one hand I want to be able to validate the business asap, on the other hand I also want to follow best practices in terms of coding & make sure I'm not digging my own hole by pushing out unmaintainable, untestable code.
Curious on everyone else here balances these two things out?
All the best,
You have nothing at stake when validating an idea so you don't need the safety of tests.
You should have a way to get notified when an error happens, though. Use something like Rollbar (they have a free plan) so you can fix errors as they happen. It's ok to be reactionary with bugs early on. If you have decent visibility into the errors, then you can sleep at night and skip writing tests for now.
Thanks for the reply! I thought about having some error monitoring integrated at some point before release, was thinking of Sentry, but will also definitely check Rollbar out as well, as I didn't know about them.
If you haven't validated the business idea, it's much too early to write tests.
It's unlikely you're moving at the veolcity which would allow you to create an insurmountable future problem (and if you ARE moving at that kind of velocity, you should be pouring that energy into idea validation). Code is malleable and it's easy to get a coverage report in any language; you can add the tests later.
Thanks for the reply!
Indeed, this approach shapes more and more like the consensus, however, @openlowcode had a good point about testing only the very "complex" logic which would benefit from having some automated testing, which I do find as being a valuable point.
Don't waste time on tests at this stage.
As you start to receive feedback you will have to implement changes and keep validating as fast as you can. The need to update tests will slow you down big time.
Plus there is no point in tests or code quality at all when you need to validate the idea. Like at all.
Telling you as I guy who is guilty of that myself. Let your inner developer go on vacation for a while 🤣
Thanks for the reply!
One argument a good friend of mine (and of the best devs I know) has in favour of tests is that in the long run they save time. He basically says something in the lines of "think of the tests as being all the postman requests you send while testing manually, but saved & executable over and over again".
It's hart to reason against writing tests when thinking about them this way, but I also see how maintaining the tests (since they're still code...) could act as another "distraction" from the product building process
Haha, I'm quickly discovering that this is harder than it looks :-D
In your situation, for sure, you should put together a crap prototype as soon as you can to validate the app with potential users. By crap, I mean that features may be limited and it will certainly not follow all coding practices, probably not be scalable... I think though that you should focus in making the product decent from the users perspective : quite robust, quite beautiful, as something ugly or unstable may discourage potential users quite quickly, or hurt your credibility.
Even after your product has found its market, I think there is a risk is automating too many tests, and having less time as a result for improvements visible to the user. Instead of the usual sequence of write tests, write code, use code in production, have problems, refactor, I would sometimes suggest the alternative sequence of write code, use code in production, have problems, write tests, refactor. Decision on which route to follow should be for me: is the component I am coding so difficult that automated tests will help me with the coding ?
Thanks for the reply!
This is an excellent point. Also mentioned this here, one friend of mine regards tests as "being all the postman requests you send while testing manually, but saved & executable over and over again".
I believe this coupled with what you said about testing more or less only the most complex components will drive my approach in terms of what to test & what to leave until after launch and/if the whole thing gets off the ground.
Whether to write tests or not seems dwarfed when compared to this one. A challenge for another day though!
This comment was deleted 6 years ago