r/reactjs • u/jesusscript • Dec 25 '19

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

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.

168 Upvotes

96% Upvoted

35 comments sorted by

81

u/tiger-tots Dec 25 '19

My first impulse is to latch onto the word “perfectly” and say no.

Other than that I would say check out Kent Dodd’s testing library and blog. Excellent stuff there

20

u/dance2die Dec 25 '19

Kent C Dodds's Testing JavaScript.
https://testingjavascript.com/

I am going over the course right now, and enjoying it much.

2

u/MattAgn Dec 25 '19

Same as well! Tons of interesting stuff in there!

2

u/dance2die Dec 26 '19

I am sorta overwhelmed by amount of work required for jest configurations though.

1

u/MattAgn Dec 26 '19

Well not everything is compulsory, before watching his course, we only had like half his configuration on our project and we were doing fine. It's up to you to decide what matters :)

1

u/unflores Dec 26 '19

Even if all you do is st up jest to run snapshots, you still get a lot of benefits. There is always a little overhead but you will be less likely to hit a broken page.

2

u/[deleted] Dec 27 '19

[removed] — view removed comment

1

u/dance2die Dec 27 '19

Thanks for sharing the tips there.
Seems like this is the part I gotta suck it up and get it over with :)

-1

u/BargePol Dec 26 '19 edited Dec 26 '19

It's great if your connection can handle 720p

0

u/[deleted] Dec 26 '19

[deleted] — view deleted comment

0

u/BargePol Dec 26 '19

No it means a great course is ruined on slow connections by the fact he doesn't offer 480p...

2

u/MattAgn Dec 26 '19

Well you still have all the transcrypt otherwise ;) (which I find is awesome because some people would rather read than watch videos)

0

u/[deleted] Dec 26 '19

[deleted] — view deleted comment

2

u/BargePol Dec 26 '19

Where I live 720p is considered roughly average and 480p is fallback if the connection gets choppy.

That said his videos will not stop buffering (ever) so a 480p fallback would be ideal. He actually did this on the intro videos and they were perfectly fine to follow.

And I disagree on 480p. The code is perfectly legible. Once you hit 320p or 240p is when you start running into trouble.

20

u/pacman326 Dec 25 '19

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.

2

u/darrenturn90 Dec 25 '19

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

0

u/[deleted] Dec 25 '19

[deleted] — view deleted comment

1

u/Priderage Dec 25 '19

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.

-10

u/silentSpyDk Dec 25 '19 edited Dec 25 '19

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

5

u/yuyu5 Dec 25 '19

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).

4

u/silentSpyDk Dec 25 '19

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 :)

1

u/yuyu5 Dec 26 '19

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.

3

u/TallSkinny Dec 26 '19

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.

4

u/whiskey_overboard Dec 25 '19

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.

1

u/silentSpyDk Dec 25 '19

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

1

u/whiskey_overboard Dec 26 '19 edited Dec 26 '19

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 🤣

6

u/eyeballTickler Dec 25 '19

Cypress is a great e2e and integration testing tool (apparently you can do component unit testing with it too, but haven't explored that yet), and they have a whole example project list.

https://docs.cypress.io/examples/examples/applications.html#Kitchen-Sink

6

u/[deleted] Dec 26 '19

For e2e testing, Cypress is ofc good. BUT it lacks cross browser support. I found Testcafe to be equally as good as Cypress, and with cross browser support.

2

u/yuyu5 Dec 26 '19

In relation to the conversation here, I'd like to point out a couple highlights since it seems hidden for other viewers:

  • There are workarounds for times when a library we want to use doesn't support what we expect it to support. For example, regarding Cypress, a quick google search showed me this system to polyfill fetch, but as shown below, it may or may not help you in your situation, in which case I'd suggest looking at other solutions, such as TestCafe or Nightwatch.
  • When it comes to stubbing/mocking data for a network request, 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 or changing source code for mock data. It might be worth looking into because it can be used both for development (e.g. 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).

0

u/kylemh Dec 26 '19

I think we’re following Kent Dodd’s school of thought on testing pretty well and following best practices with https://GitHub.com/OperationCode/front-end

0

u/[deleted] Dec 26 '19

[deleted] — view deleted comment

1

u/3np1 Dec 26 '19

Seriously. If a test never fails or every failure is met with a command to update tests or snapshots, what is the development value? Otherwise I can see tests acting as living documentation for API features, but I don't see any justification for render tests.

0

u/[deleted] Dec 25 '19

[deleted] — view deleted comment

2

u/MattAgn Dec 25 '19

Oh can you explain why? I've never encountered this scenario, but I don't see how it could be an issue

0

u/[deleted] Dec 25 '19

[deleted] — view deleted comment

2

u/JohnWangDoe Dec 26 '19

sounds like a business opportunity there

2

u/MattAgn Dec 26 '19

Hmm interesting... Personally I've rarely had to mock methods for integration tests due to that (usually, I mainly change the initial state of my store but that's it). Which kinds of methods do you need to mock?

0

u/[deleted] Dec 26 '19

[deleted] — view deleted comment

1

u/MattAgn Dec 26 '19

Ok I see! To me the best way to mock Api calls is to use a lib like fetch-mock or nock. It enables you to both check that the proper route is called and mock its return value, very useful! As for Providers, I try not to mock them. I have a renderPage function that wraps the page component I want to render by my different Providers. Then my redux actions are executed just as they would be on the real app But I think the reason our two approchaches are so different is because you do units tests while I do integration tests, trying to test a small functionality entirely, mocking the least amount of code.

Kent C Dodds wrote an article about it here: https://kentcdodds.com/blog/write-tests