Issue 1:
Do you want to request a feature or report a bug?

I'm not quite sure if feature/bug... I have an error boundary, and I want to test that it works correctly, but it produces a big console.error and there doesn't seem a great way to get around it.

What is the current behavior?

When an error is captured by the error boundary, it still logs to console during tests, making it look like something failed but it is expected (because I am testing error boundary) in this case.

console.error node_modules/react-dom/cjs/react-dom.development.js:9747
The above error occurred in the <Child> component:
in Child (at ErrorBoundary.test.jsx:20)
in ErrorBoundary (created by WrapperComponent)
in WrapperComponent

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

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:

Error Boundary:

import React from "react";
import PropTypes from "prop-types";

export default class ErrorBoundary extends React.Component {
static propTypes = {
children: PropTypes.oneOfType([
PropTypes.node,
PropTypes.arrayOf(PropTypes.node)
]).isRequired,
render: PropTypes.func.isRequired
};

state = {
hasError: false,
error: null,
errorInfo: null
};

componentDidCatch(error, errorInfo) {
this.setState({ hasError: true, error, errorInfo });

// if we have Bugsnag in this environment, we can notify our error tracker
if (window.Bugsnag) {
window.Bugsnag.notify(error);
}
}

render() {
if (this.state.hasError) {
return this.props.render(this.state.error, this.state.errorInfo);
}
return this.props.children;
}
}

ErrorBoundary.test.jsx

import ErrorBoundary from "./ErrorBoundary";

const Child = () => {
throw "error";
};

it("catches error and renders message", () => {
const wrapper = mount(
<ErrorBoundary render={() => <div>Error has occurred</div>}>
<Child />
</ErrorBoundary>
);

expect(wrapper.text()).toEqual("Error has occurred");
});

What is the expected behavior?

I'm not sure exactly... here is a way I can sort of temporarily pause console.error logging during the course of the test, but it seems messy. How should error boundaries be tested?

Here is a hacky solution:

import ErrorBoundary from "./ErrorBoundary";

const Child = () => {
throw "error";
};

const pauseErrorLogging = codeToRun => {
const logger = console.error;
console.error = () => {};

codeToRun();

console.error = logger;
};

it("catches error and renders message", () => {
pauseErrorLogging(() => {
const wrapper = mount(
<ErrorBoundary render={() => <div>Error has occurred</div>}>
<Child />
</ErrorBoundary>
);

expect(wrapper.text()).toEqual("Error has occurred");
});
});

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

16.2 (with enzyme 3.3)

Issue 2:
(This is a repost of jestjs/jest#4597 by @erikras.)

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

Somewhere in between?

What is the current behavior?

When I'm running tests on my library, there are some behaviors that I want to test do throw an error. These currently result in:

Consider adding an error boundary to your tree to customize error handling behavior.
You can learn more about error boundaries at https://fb.me/react-error-boundaries.

...being output to the console. This error is great in an application, but not so great for a library test.

What is the expected behavior?

It would be great if I could do something like:

expect(() => {
TestUtils.renderIntoDocument(<DoSomething naughty/>)
})
.toThrow(/Bad developer!/)
.andCatch() // <---- prevents React 16 error boundary warning

Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.

jest@21.2.1
react@16.0.0
react-dom@16.0.0

See also

#11083

#10474 (comment)