Production Check in react-test-renderer

[halovanic]

When upgrading to 16.0.0 from 15.6.1, react-test-renderer started failing on my tests with the message:

test renderer is not available in production mode.

I have in fact been running unit tests using this renderer during my production build.

I'm trying to understand: why was this restriction introduced? I saw the change was made in #9514 but couldn't find any explanation on the pull request or the documentation as to why production mode is now disallowed for this renderer.

Thanks,
Alex

[gaearon]

Mostly because it was never intentionally supported and minor things could always break without us realising. It also skips important warnings that should generally be caught at the testing stage. I'm curious to hear what use case you have for running them in production. If it was accidental, can you switch to development mode for tests instead?

[iamdustan]

👋 We have a use case we’re we’re using the JSON from the test renderer to power some search/analytics features rather than using the html from using the server renderer. 😅

[halovanic]

My use case was much less cool than @iamdustan's: it was more simply that I was running a production build and wanted to test against what I was actually building for end users, not something different. React in particular strips things out in that mode (I doubt its production mode is broken), but hypothetically I or another library could have written all sorts of code that doesn't work outside of development mode.

[gaearon]

Fair enough. I don't mind relaxing that and adding the support back in.

[gaearon]

Note to self: if we re-enable this, should also re-enable it for shallow rendering and TestUtils.

[aweary]

@gaearon this is also one potential solution to a problem outlined in #10474. Right now it's difficult to test error boundaries with the DEV build in a real browser since the error ends up being thrown asynchronously. With a production build, it should let users use the standard expect(render).toThrow() assertions since the error utils use a typical try/ catch block.

It's not the best solution to that specific problem, but at the very least it's a solution.

[gaearon]

Fixed in #11112.