-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jest master doesn't seem to catch errors originating from React #4764
Comments
Pretty sure this is related. Will test in the office. |
Yeah, based on your explanation of how React emits browser errors, it looks like a smoking gun. We can make the behaviour opt-out to accommodate React's use case, but I don't think it should be reverted. |
If this is working as designed, what is the suggested way to test catching errors inside React components? It currently seems impossible. (To be clear, it doesn't affect just React test suite, it affects any project using React.) |
Would it make sense to somehow track if we’re inside |
If you can make that work, I’d be ok with that as a solution.
…________________________________
From: Dan Abramov <notifications@github.com>
Sent: Thursday, October 26, 2017 11:11:18 AM
To: facebook/jest
Cc: Subscribed
Subject: Re: [facebook/jest] Jest master doesn't seem to catch errors originating from React (#4764)
Would it make sense to somehow track if were inside toThrow() and in that case, not treat it as an unhandled error?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#4764 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAA0KKficrUYb3Z4xSxDlMt5oTfmQeGrks5swFrGgaJpZM4QG3MP>.
|
What about instead of emitting |
Here's an integration test for ya. #4767 |
Seems like this fails the test from #4669. It never finishes. |
Maybe we could override |
That sounds interesting. Something like const originalAddListener = this.global.addEventListener;
this.global.addEventListener = (name, ...args) => {
if (name === 'error') {
this.global.removeEventListener('error', this.errorEventListener);
}
return originalAddListener(name, ...args);
}; ? |
Seems to work. I'll push it to Dan's branch to trigger CI |
@gaearon something seems strange with this process. Although jest now catches the error because the test passes, yet it still displays them to the console. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
As reported in #4761 (comment), I tried
21.3.0-beta.3
on React codebase, and tests likenow fail. (The error blows up the test despite bring caught.)
However, they pass with
21.2.1
.To repro, you can take the test above, put it into
ReactDOMComponent-test
on React master, update Jest packages to21.3.0-beta.3
and runyarn test ReactDOMComponent-test
.I haven't had time to verify if it's isolated to React Jest setup or not. But if it affects us, could affect someone else (or everyone) too.
The only unusual thing we do in React wrt error handling is that we wrap our code into a browser event so that browsers report unhandled (but caught and rethrown by us) errors as unhandled. This used to work with Jest too. You can disable this logic by changing
__DEV__
tofalse
here and then you'll see it goes back to normal (test passes).So something related to how errors are handled in jsdom browser event loop has changed, and will likely break any tests relying on throwing (and intentionally catching) errors with React 16. Maybe jsdom was updated or something like this?
Note that if this got broken, it will affect anyone using React, not just us.
Here is the diff of lockfile: https://gist.github.com/gaearon/fc30d89381e6b4c6a2494b66f04455cf. Something here causes the issue.
The text was updated successfully, but these errors were encountered: