Tried to render a non renderable component

[shrynx]

Thanks for making this project. This will simply a lot of my tests and test configs.
I am starting to replace enzyme with it wherever possible

• react-testing-library version: 1.6.0
• node version: 9.4
• npm (or yarn) version: 1.5.1
• jest version: 22.4.2

Relevant code or config

import { render } from 'react-testing-library'

global.console = {
  error: jest.fn(),
}

...

test('should warn incase child is not provided', () => {
  render(<TestComponent />)
  expect(global.console.error).toHaveBeenCalledWith(`You must provide children`)
})

What you did:
Tried to render a non renderable component , to test if my custom console errors are thrown

What happened:
render throws error on non-renderable component rather than silently failing

Nothing was returned from render. This usually means a return statement is missing. Or, to render nothing, return null.

Reproduction repository:
currently i am playing with react-testing-library and trying to replace enzyme on a small react util i wrote.

This is a sample test currently written in enzyme, but on my local branch i am replacing it react-testing-library.
https://github.com/shrynx/react-render-function/blob/master/tests/index.test.js#L118

Problem description:
TestComponent shouldn't be able to render without Children, and for missing Children i am throwing errors from inside TestComponent which i want to test for using jest (i.e, test console.error message).
But the test fails at render itself throwing, rather than throwing my error.

Earlier i was using enzyne and used shallow in the same way i used render above and this used to work.

Suggested solution:
The render should fail silently or better if could be configured to not throw error, maybe like

const {container, unmount} = render(<Component />, {renderError: false})

I can try making a PR for it. should be easy to put try catch on ReactDOM.render and not throwing errors only if user has configured not to.

[shrynx]

@kentcdodds i added a PR implementing the mentioned fix
#19

[kentcdodds]

Hi @shrynx! The reason is that it overcomplicates the library (both in implementation and use) and goes against the guiding principles. I would therefore recommend adding a try/catch in your test code around the render call as this will make things more explicit.

Based on your project I think you came up with an alternative. I'm glad. Good luck! And thanks for understanding :)