How makers stay productive

That will kind of depend on you. In opsdroid we decided to aim for 100% test coverage just to make sure that everybody will write tests that will actually cover the whole PR and avoid PR's that lower the coverage and get to a stage where only 50% is covered.

--edit--

Oh and how to go with test, I'd pick a class and start from someplace, maybe the most important bit of your code perhaps

You can start out with building tests for the components in your app which you feel are the most fragile. Which parts of your code do you trust the least? Which ones have the most complex interactions?

I prefer not to focus on unit but integration tests, basically test the API response (in my case my backend sends out JSON response).

The point being, I focus on what affects the user the most when broken. The API being the interface here and if something breaks in the API, the UI breaks (single page app in React).

I would also test critical segments in React. Again following the user. Tests take a lot of time to write and as a solo founder I have to focus on things that have biggest possibility to break the UI flow.

Disclaimer: these are learning from the last few years of testing in startups, not yet started in Dwata.

Start small, Unit testing is great for that.

It all becomes about testing different calls and getting the right responses. You could just pass a unit test with a 200 response or you could tell them what kind of data you would expect back.

How far you test is really up to you there isn't a golden rule here. But if you start small and take some parts of the app that you could wrap some unit tests around different functions it would be a great start.

Maybe try and look at what the core functions are for the app and build some unit tests for those. Then in time you can add on more as you go.

Don't give yourself a target for code coverage it's not as important has having some sold tests around the core of your app.

Too often I've seen people try and go from 0 to 80% code coverage and then they miss the important parts of their app because those where harder to test.

the most important functionality first

for example, i'm building an e-commerce, erp system. the most complicated thing is the calculations. vat, products, voucher codes and all that in combination.

i am just about to build different scenarios. these are then constantly tested.

100% coverage is simply exaggerated for some things. that's nice of course, but what many people forget is that your tests can also have bugs and then it can happen that you fix your bugs for your tests and don't even work on the actual product.

you have to find a good middle way and it always depends on which software it is. at a jquery slider i would not care about the code coverage :D. at a bank software it looks different ;-)

I NEED TO KNOW THIS

I haven't created unit tests EVER, and I'll start doing right after instatus launch so i don't ship bugs.

Don't lie you guys making unit tests, I know you dont ;) muhaha

I've used a bunch of different approaches to testings over the years. These days my approach really depends on what part of the project I'm working on and how complex or critical it is.

Some people use testing to drive the design (TDD) but in my experience it doesn't really lead to a better product design, just a more testable design. With a bit of experience you can make your code testable without thinking about it too much. Good product design comes from really thinking about the problem you're solving from the right perspective imho.

Some of your code will naturally be solving complex problems. This is great place to have unit tests because as it evolves you want to make sure you haven't broken things you've already got working. On the flip side, you'll also have code that's so simple it obviously works. Keep in mind that unit tests do have a cost to maintain.

One unit test on its own never really feels worth the effort. The real benefit of unit testing comes when you've built up a large set of them over time and run them on every commit. Having 100 or 1000 good unit tests can provide an incredible amount of confidence.

There's also "bad" tests that aren't worth having. These tend to break a lot for the wrong reasons and rarely if ever break for the right reasons. Sometimes you'll even find tests that don't actually prove anything. In these cases, delete the tests, it's better to have no tests than a bunch of bad ones.

For Indie Businesses I recommend only do E2E testing. You have limited time, and want to make sure that nothing goes completely messed up with your limited time, rather than unit test every single thing.

You can start unit testing once you have customers and more time.

Cypress is fairly easy and quick to start testing your app.