Effective testing strategy for a simple project

So we know how to think about what to test for individual components and even pages of our app, but where do you start? It's a bit overwhelming. Especially if you're just getting started with testing in a large app.

So here's what you do, consider your app from the user's point of view and ask:

What part of this app would make me most upset if it were broken?

Alternatively, and more generally:

What would be the worst thing to break in this app?

I'd suggest making a list of features that your application supports and prioritize them based on this criteria. It's a great exercise to do with your team and manager. This meeting will have the side-effect of helping everyone in the room understand the importance of testing and hopefully convince them that it should receive some level of prioritization in all the other feature work you need to do.

Once you have that prioritized list, then I suggest writing a single end to end (E2E) test to cover the "happy path" that most of your users go through for the particular use case. Often you can cover parts of several of the top features on your list this way. This may take a little while to get set up, but it'll give you a HUGE bang for your buck.

The E2E tests aren't going to give you 100% use case coverage (and you should not even try), nor will they give you 100% code coverage (and you should not even record that for E2E tests anyway), but it will give you a great starting point and boost your confidence big time.

Once you have a few E2E tests in place, then you can start looking at writing some integration tests for some of the edge cases that you are missing in your E2E tests and unit tests for the more complex business logic that those features are using. From here it just becomes a matter of adding tests over time. Just don't bother with targeting a 100% code coverage report, it's not worth the time.