Cannot suppress error boundary output using react-test-renderer

[mpeyper]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

When following @gaearon's example on how to suppress the error boundary logging in tests expecting errors, it appears to not be working in 16.8.6 (I'm not sure which versions after 16.4.3 is has worked for).

Here is a sandbox.

I had to make a change to the renderError as it looks like the way codesandbox executes the script cause the event.error to be hidden from the code (it just had an object with isTrusted: true on it - google led me here so I changed it to just count the number of errors).

I also made a change to be able to use react-test-renderer as well as react-dom as I'm actually after a way to suppress the error using the test renderer for an issue raised in react-hooks-testing-library.

In my sandbox, you will see the errors

The above error occurred in the component:
in Darth
in TestBoundary

React will try to recreate this component tree from scratch using the error boundary you provided, TestBoundary.

and

The above error occurred in the component:
in ObiWan
in TestBoundary

React will try to recreate this component tree from scratch using the error boundary you provided, TestBoundary.

get printed to the console, despite the event.preventDefault() call.

The other main thing to note is that the react-test-renderer test does not pass, which implies the error listener is not firing for it, which sort of makes sense to me as it's not using the DOM, so it's not erroring on the window, but my understanding of these things is somewhat limited.

What is the expected behavior?

Assuming the expectRenderError, TestBoundary and handleTopLevelError code is sufficient to suppress the output as indicated in #11098, I would expect the react-dom test to produce no output.

Assuming the same setup should also work for react-test-renderer, I would also expect that test to have no output.

If either of these assumptions are wrong, how should one go about suppressing the output in these tests?

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

react: 16.8.6
react-dom: 16.8.6
react-test-renderer: 16.8.6

[milesj]

Bumping this. I'm trying to solve this in Rut, but it's turning out to be quite difficult (I'm not using JSDOM). https://github.com/milesj/rut

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

[milesj]

😭

[AlanSl]

An ugly workaround while waiting for a proper fix here is to temporarily replace console.error with a no-op in expected error tests.

A util function like this works for both this issue and another issue of coverage not being counted in expect(render(<>)).toThrow():

// In test utils
const consoleError = console.error
function catchErrorSilently(fn) {
  try {
    console.error = () => {}
    fn()
  } catch (error) {
    return error
  } finally {
    console.error = consoleError
  }
}

// In tests:
expect(catchErrorSilently(() =>
  render(<SomeComponent someProp="invalid prop value" />)
)).toBeInstanceOf(Error)

Or for a broader scope:

const consoleError = console.error
beforeEach(() => {
  console.error = () => {}
})

afterEach(() => {
  console.error = consoleError
})

[stale]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[mpeyper]

No stalebot, not stake... Ignored... Ignored is the word you're looking for. Almost a year now and nothing. Is the test renderer even supported any more?

[stale]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!