How important is testing for small web apps?

Like @farez said, learn how to write testable code and also learn how to write good tests.

Answer to whether a specific app should be tested is: it depends. If your app contains something truly critical, then consider writing tests. It might be for example one of the following:

• Payments (or any sort of handling related directly to money)
• Business logic, that has a crucial side effects (again, like calculations to come up with payment sums)
• Other crucial logic that produces data that keeps the whole system working

But there is no one-rule-fits-all-cases in development as you will soon come to learn once you advance as a developer :)

Hope this helps!

The other things to watch out for are:

• that the web-app grows, but it never seems quite the right time to add tests, or there isn't enough time.
• that the best way to ensure that the code is testable is to write tests for it.

If it's gaining traction and / or reliability or robustness becomes an issue, then it is probably time to add some tests!

Yes.

Even if you don't think you'd be using it, learning to write testable code builds good coding habits.

But tests are not just for "big" apps. Even small good open source packages or modules come with tests. And practicing writing tests early on will prevent you building bad coding habits that's difficult to undo later on.

Hope that helps.

Since you are learning - YES! Learn to write tests. Write the tests.

If a false dichotomy. I've written my fair share of untested code and it always bitten me in the ass. You save so much time down the road by writing some simple assertions. Also helps with knowing your functions are doing exactly what you expect.

This mostly relates to backend code, UX is different since there tends to be less coupling (although still nice to test user flows).

It depends. But regardless, here is what I think about tests:

• they help bring clarity because you can only write tests once you know well enough what to build.
• they help me write defensive code. It's harder to introduce regressions when you have tests that are run as part of your CI pipeline. Tests help catching regressions on a codebase that is moving fast.
• Tests are faster than writing, saving, reloading the browser, clicking here and there - particularly for anything computational.

If a feature relies a lot on visuals and little in business logic then you probably shouldn't be wasting time with any other form of testing but manual/visual testing.

Hey Vivek—that's awesome, what course are you using?

IMO it's incredibly valuable to learn how to write tests, especially if you'd like to work as a developer either in a consulting capacity or at a company. Writing tests is a skill that most developers utilize in their career.

Sometimes it is much easier to write failing tests before writing actual logic I think, so you write what test should do in that particular case and then fix it right after in actual code and repeat.

It's an interesting question. I plan on adding tests to my MVP before launch to reduce friction; I don't want my customers running into frequent bugs if I can help it.

That said, here's 2 scenarios in favor of not writing tests for your MVP:

• You sell the product or receive a high volume users, you may end up refactoring your MVP to make it more team friendly
• You are racing to market for a various of amount of reasons (investor pressure, competition, opportunity, etc.)

And here's 2 scenarios in favor of writing tests for your MVP:

• By using tools like TypeScript and automated tests, your first iteration is stable and you reduce friction with conversions
• By reducing the amount of bugs in your code from the get go you reduce support tickets

Tools for a job, it's your preference. I like writing tests, but what tests should do is increase your confidence in your code, not just be written for coverage or 'just because'.

EDIT: As an indie hacker you will always wage the internal war between building quality software and satisfying business needs, as sometimes they do not exactly align the way you might want them to. We experience this at software jobs as well. As with all things, balance is key here.

EDIT: fixed spelling and grammar mistakes

I think you are planning to build the app that's useful for people (since you're here). I'd never bother with tests. It's waste of time. Teting is for a company with an already established product.

In indiehacker case, you will write many codes that go wasted because no one uses it. That's fine. You just focus on what your users want.

No one cares whether you have 100% test coverage. That is for professional engineers to make the managers happy. Your jobs will be to write codes quickly that work and make your users happy. Repeat.

"Don't fall in love with your own code."

It’s not about the size, it’s about changes frequency. If you’re on mvp track just go with some automated e2e tests as opposed to hiring a qa. If you’re on growth track - start adding unit tests.