Do you test?

It's tempting to skip testing, but I think that's a wrong choice.

Testing functionality manually often takes just as much time. Why not just write the test script, that you can keep using going forward?

Keep in mind: MVP doesn't mean low quality.

At SEOly, we decided to write as little code as possible until we have firm validation of the solution. This means that we've sacrificed quite a bit of the usually code quality metrics in favour of business development.

Testing was not one of the things we sacrificed. We never aimed for 100% code coverage (since I believe it's a pointless metric anyway), but we do tend to focus mostly on integration tests. We use an outside-in testing strategy, aiming to cover as much spec room as possible with as fewer tests as possible.

Let me know if you want me to elaborate on any of this

There's this concept that developing with tests slows you down but, in reality, I think that's just people that are not used to write automated tests. When you develop code, you still spend time starting the services and manually testing. It would be a lot better if if you automated the process, wouldn't it? :) I'd say core functionalities should all be tested, either you go with end-to-end, or unit tests.

Test the core functionality that keeps my MVP alive.

Thanks for all the replies everyone, some really cool insight here

Regulary I write only test for very complex logic to be able to change it later without the risk of breaking it.
For backend applications I would add some postman because the effort of implementing those is low and it provides a basic safety net.

I skipped in the beginning until every change I made added regressions.

It's clear that I was being slowed down from not testing.

Overall, it depends a lot on the product.

1. Do you already have customers? Yes, consider testing quite seriously.
2. Does the product have complex flows/state/etc.? Like in my case, yes, test the painful parts
3. Do you handle billing? Do test

Something that the more engineering-minded won't agree: don't unit test.

Write good Cypress tests on the most important parts of your application. Write tests that give you confidence and skip the non-essential.

Integration tests in their classic definitions are usually too synthetic and miss out the edge cases, in my opinion.

I prefer unit testing the core, most important logic (getting to full coverage for the deepest business logic while neglecting the rest makes sense to me), and using two flavors of system tests for the rest:

• If you can write an end to end test for the main use cases, this is great and can be very useful.
• Even if you do have e2e, but especially if you don’t - create a script which can generate randomized data (bonus point: do this via your exposed API and not directly in your data store). This will help getting a feel for your UX, and can make manual testing feasible.

This sums up a lot of my thinking: https://kentcdodds.com/blog/write-tests

Tests should give me confidence in my application, but I also want to iterate relatively quickly, so I try and balance that.

I don't write unit or integration tests at all for now. But I do loads of exploratory tests as I change things and I use my own app a lot. I am a single developer, and I don't intend on changing this until someone else joins the team and has to understand and touch the code, in which case tests will be very useful.

I test when it makes sense. TDD helps me about 50% of the time and when it does, I'm glad I'm doing it.

Don't follow a hard or fast rule. The ROI of testing in the early stages fluctuates based on numerous factors. Some that come to mind are:

• how critical is the feature
• how complex is the logic
• have you built something like this before
• how committed are you to this project
• how difficult is this feature to manually test
• Is it likely I break this code in the future once its written

So, the answer is, it depends! 🤷‍♂️

Any complicated/hard to understand/easy to get wrong business logic: Full unit tests.

A component where a lot of bugs seem to be popping up for end-users: Integration tests to ensure correct behavior and ensure regressions don't occur.

If my testing preferences were a pendulum swinging, I'm currently on the lighter side of things. I used to go for 100% unit test coverage with lots of integration tests, and it's not clear to me that they always pay off. Especially in an MVP scenario, where the underlying concept can shift dramatically in a short period of time, you just end up writing a bunch of tests that you immediately throw away.

For personal stuff, my philosophy so far is to test when:

• it would take more time to manually test different scenarios (e.g. now I have a model that spawns multiple children, which is a bit more tiresome to test manually)
• there are many users (the more users there are, the more coverage is probably important)
• the feature has low-tolerance for error (e.g. if payments were involved - though I haven't had this "problem" much yet :sad:)

A little bit different opinion here.
I used to write every single tests for both my front and back end codes.

Then I refactored almost entirely my app so that the relevant parts that were tested become deprecated.

And I just caught myself refactoring or changing some features primary behaviors, that lead to a lot of tests rewritings.

So I just decided to stop completely for a while writing tests. I’m aware that I should be writing tests for at least the most crucial parts for my app, but there is just no easy way to test automatically something like Apple Sign In with FaceId, where you ended up just mocking fake authentication without truly test it out.

So now, my app has zero tests written and is at the moment not an MVP, just an app with a few hundreds of MAU.

Instead what I did is to integrate Sentry, to send me in real time errors that happened in the app, and send me directly a Slack notification.

That way, I know exactly where the app bugs/crashes, so I can know the root and fine tune my code.
I consider that within the app there are things that are worth testing (authentication, first onboarding experience etc) and things that are okay not to tests and when it bugs a little bit (a button that randomly doesn’t work the first time you click but does so when reclicking, okay that’s a bad example but you get the idea).

That helps me speeding up the app development, since I’m still at the “features exploration” kind of phase 😯

Yes but mostly for client work or when a project reaches a certain point, a quick MVP I wouldn't bother. I'm not too strict about my test definitions, they're mostly unit tests but I often let them creep into more integration style tests where I'm setting and tearing down databases etc since I find this gives me the most bang for my buck so to speak and tests that the whole system works. I tend to focus on model type code and business logic, I try to build UIs that are logic-less as much as possible and therefore wouldn't bother testing them.

Do you test?
Yes, yes, yes. I don't have the luxury to not have automatic tests.
Do you test MVP?
Here your main goal makes the product as fast as possible. Usually, MVP is not a big product that has only a few features where can be tested by hand. But the moment after you validate MVP next release must have some test coverage.

I would say it depends what your mvp is validating, most of the time it is to validate idea hypotheses and audiences etc. But if you're sure what to build, then you can spend more time on technicals.