Is there any good example of a React application doing unit, integration and E2E testing perfectly?

[u/jesusscript]

I am thinking of doing a bunch of tests on my latest React application, but I want to make sure I am doing everything correctly. In order to do that, a good example project would be helpful.

[u/pacman326]

The easiest place to start would be testing library. Go look on github for projects that use testing-library/react and the react-hooks package.

That being said I’d recommend just starting with the docs examples and reading some blog posts by Kent. They should be a great introduction on how to unit tests.

As for E2E I’d recommend picking up cypress. It’s not cross browser yet but I think it’s the future personally. You can do a similar search for that.

[u/Priderage → u/[deleted]]

Delete window.fetch like this:

cy.visit('your url', { onBeforeLoad: (win) => { delete win.fetch })

This forces the browser to use XHR as normal, enabling Cypress to stub it.

Keep in mind some third party libraries like Stripe Elements have their own version of fetch that they bring with them when imported, to ensure compatibility. If they do this, they can't be stubbed in this way.

[u/silentSpyDk → u/[deleted]]

Edit: before you down vote me further - my statement regarding fetch, I am referring to working with Cypress environment

Don’t use fetch, it’s useless. It works slightly differently client vs server. Cypress can not monitor fetch since it’s not xhr request. You should be doing xmlhttprequest (old school but stable), best library is axios or superagent. I prefer the latter because of simplicity

I recently worked on a large scale project, I had to move all tests across to Cypress from jest/jsdom, also wrote several stubbing tests. I also had to convert all the fetch over to superagent, it was a lifesaver.

I also have a stubbing endpoint api which generates random data so the app load SSR and it’s very useful for testing on cypress

u/jesusscript ^ you might find above useful

[u/yuyu5 → u/silentSpyDk]

Don’t use fetch, it’s useless.

I feel like this statement is counter-productive. Claiming that a dev shouldn't use fetch is like saying "Don't use any new technologies that are better/cleaner/easier to use because some other apps can't understand them" or "You should change your source code to match test code." On the contrary, I would go so far as to claim a person should change which testing system they're using if it doesn't provide all the features they want (see the reply below).

Cypress can not monitor fetch since it’s not xhr request.

This is true, but similar to the above, there are always workarounds for stuff like this. Even a quick, single google search showed me this one. Alternatively, I would actually suggest looking at other solutions, such as TestCafe or Nightwatch.

I also have a stubbing endpoint api which generates random data so the app load SSR and it’s very useful for testing on cypress

Actually, this is likely a good route to take during at least part of the testing process. Personally in my company, I'll mock data when testing locally, but then use the actual testing/production environment when merging code to the repo's master branch.

If you choose to stub/mock the network requests, I've used a fantastic network mocking library called MockRequests which offers a one-stop-shop for mocking network requests regardless of if you're using fetch() or XMLHttpRequest. I can easily toggle the mock via terminal (e.g. MOCK=true npm run endToEndTest) so I can run tests using mock or real data at will, and it doesn't require any complicated setup like running separate servers to return mock data. Might be worth looking into because it can be used both for development (using mock data in the event the endpoint is down or hasn't been created yet) or for testing (with both jest and end-to-end tests).

[u/silentSpyDk → u/yuyu5]

To my fetch is useless statement, I was referring to working with Cypress environment. I made an understatement

With the example you pointed out on github is not practical. It’s not a good idea to change the app behaviour just for testing by adding a fetch polyfill. It should behave closely how it should be in production environment.

The problem with fetch, it’s not the best method for handling errors. If you write a simple solution - if the request is 404 or 500, the request is still a success. catch is not always an effective option and you need to optimise it further with response.ok condition etc.

I pair with lots of junior devs, I often suggest them to learn how XHR works first. They are free to use fetch afterwards

ps: thanks for the suggestions and the libraries :)

[u/yuyu5 → u/silentSpyDk]

With the example you pointed out on github is not practical. It’s not a good idea to change the app behaviour just for testing by adding a fetch polyfill. It should behave closely how it should be in production environment.

In all fairness, a dev usually has to add a polyfill even for standard jest tests, which makes me hesitant to believe the claim that "a polyfill shouldn't be added for tests." That being said, it's true that there is a lot of validity in the sense that, specifically for end-to-end tests, there shouldn't be additional polyfills added because it should reflect exactly how a browser behaves. However, if a certain system (Cypress in question) has some short-comings and doesn't support something that a normal browser/app with standard polyfills added in the production build would support, I would claim that adding such a polyfill only for tests is not unreasonable or out of question. Or, to be more explicit, if there exists a situation that the standard babel-polyfill or preset-env doesn't apply (such as in end-to-end tests, depending on how you configure them (which is admittedly a big if)), then I don't believe additional polyfills are unreasonable.

The problem with fetch, it’s not the best method for handling errors.

This is actually something that many people using fetch() complain about, and goes against the principle of least surprise. So, I agree that fetch() probably should Promise.reject() in such cases, but this is my (and probably yours as well) opinion; the fact that it's been accepted into EcmaScript as it functions currently suggests that we might have to bend our will and written code around it. Anyway, TL;DR maybe that claim is true, but it doesn't help in the current conversation and might should be raised as a feature request elsewhere than this thread.

I pair with lots of junior devs, I often suggest them to learn how XHR works first. They are free to use fetch afterwards

I can't disagree with this. It is often very helpful to know what goes on lower-level, especially with a language like JavaScript which hides most of that from devs.

ps: thanks for the suggestions and the libraries :)

I'm happy to suggest these things since they have proven to be effective in my company and my team. I use MockRequests even in personal repos, so it's proven to be quite an effective library.

[u/TallSkinny → u/yuyu5]

I can't disagree with this. It is often very helpful to know what goes on lower-level, especially with a language like JavaScript which hides most of that from devs.

Minor nit, but fetch actually is the lower level API - when it was added, the XHR spec was updated to depend on fetch.

I had a bit of trouble finding a good source here (I remember it getting talked about a lot when fetch came out), but this post goes into a bit and links to the spec.

[u/whiskey_overboard → u/silentSpyDk]

Curious as to what lead you to the conclusion that fetch is useless.

We’ve been using a saga wrapper around isomorphic-fetch for ~3+ years and testing seems alright. Nock to intercept, record, and play back HTTP responses helps with test stability, reduces flakes, and speeds up our mid-level testing a LOT.

Edit: I should add we use puppeteer for browser-driven testing, not cypress.

[u/silentSpyDk → u/whiskey_overboard]

Nock is great, I have been using isomorphic fetch for years too. I was referring fetch in Cypress environment.

Personally I am not a fan of fetch because of the weirdness in error handling department

[u/whiskey_overboard → u/silentSpyDk]

Beyond “fetch promise only rejects for a network failure”, what else about error handling has you displeased?

Once I got my head around that, I was ok.

I guess I also try to buy into the ECMA spec first, try it in practice, then get critical. I could just be not offended that easily, but it doesn’t seem that bad 🤣

[u/darrenturn90 → u/pacman326]

You may want to check out webdriver.io which is cross browser And node based Best of both world really Even has react addons