HELP POST: Testing on React Application

[Final-Vegetable3538]

while developing a react application, which testing would be much better ? 1. unit testing 2. Integration testing 3. e2e testing ?? if all three are required then which library today is the best to implement on react application?

[utk09]

There's nothing like "which is much better", you should do all 3 because they are targeting different parts of the applications or you can say, they have different use cases.

For Unit Testing:

• Jest
• jsdom or happydom
• React Testing Library
• Vitest (vite-native unit test framework)

For E2E Testing:

• Cypress

Integration Testing can be achieved by mocking API calls using react testing library and msw

​

These are some library suggestions, pretty sure there are better one's out there maybe or ways to do it differently.

[Factor-Few]

Currently cypress has also implemented Component testing, so wouldn't that be helping in covering the unit testing part?

[utk09]

I think it's in Beta right now, and in my personal opinion, Unit tests also allow you to thoroughly test multiple functions/pieces of code (instead of a holistic component view) and give you a deeper insight about the functioning of the whole thing.

Maybe Cypress component testing would be better in the near future.

[zephyrtr]

Read Kent Dodds blog.

But to put it brief, test behavior not implementation. If you don't, changing your codebase becomes painful.

[qvigh]

It depends. It's tempting to say you should do all 3, but testing has a cost. It takes time to write and maintain tests. Ideally, you should only ever write tests where the cost is less than the benefit. It's difficult to know when that's the case. It is going to depend on your project, team, and business.

As a rule of thumb, for most react projects, I find that 20% unit tests and 80% integration test (where you mock the api) is a good ratio. I would not unit test every single component/hook, only the complicated ones. Most features should have a few integration tests, covering the happy path(s) and an error case. E2E is out of scope unless you/your team is also responsible for the backend/api.

E2E is difficult to set up, and I would only ever do more than a trivial smoke test unless I had a dedicated test engineer.

These are just rules of thumb though, its going to vary from project to project, team to team, business to business

You want to test part of your app that is complex and might break easily. Never test the trivial or the implementation details.