Shallow renderer and test utils bundles #9426

bvaughn · 2017-04-14T01:42:29Z

Adds new bundles introduced with React 15.5 release to master (and 16 alpha):

react-dom/test-utils

This new bundle contains what used to be react-addons-test-utils. This bundle shares things from react-dom rather than duplicates them.

A temporary createRenderer method has been left behind as a way to access the new shallow renderer. This is for the ReactNative release cycle only and should be going away before the final release.

react-test-renderer/shallow

This new shallow renderer is almost entirely stand-alone (in that it doesn't use the React reconciler or scheduler). The only touch points are ReactElement and prop/context validation. This renderer is stack and fiber compatible.

PS I used __SECRET_INTERNALS please don't fire me 😛

gaearon · 2017-04-14T18:57:29Z

src/isomorphic/classic/element/ReactElement.js

+        enumerable: false,
+        writable: false,
+        value: owner,
+      });


Related past discussion #6355

Can you verify with @sebmarkbage he has no concerns here?

Seb and I chatted about this idea in person. He didn't seem to, but I'll let him comment here (or I can follow up with him in person on Monday). Sure!

bvaughn · 2017-04-14T22:38:29Z

Adding a few more folks who may be interested in looking over this change

gaearon · 2017-04-15T12:30:47Z

packages/react-test-renderer/shallow.js

+
+if (process.env.NODE_ENV === 'production') {
+  throw Error('shallow renderer is not available in production mode.');
+} else {


Should we also throw for the main test renderer entry point then?

Or should we create prod versions of all of them? I don't see benefit but somebody might come up with a use case. Maybe just worth keeping in mind.

Or should we create prod versions of all of them?

I don't see the value of this, and it would cause problems with __DEV__ only things like the non-enumerable _owner attribute.

I'll throw in the main test renderer too, sure.

@gaearon @bvaughn I'm having a problem with these lines: I'm using enzyme and it uses shallow rendering, for tests, while NODE_ENV is set to production. So my tests are failing because of this.

gaearon · 2017-04-15T12:34:59Z

scripts/rollup/results.json

+      "gzip": 55887
+    },
+    "react-test-utils.development.js (NODE_DEV)": {
+      "size": 510240,


I think this file was deleted so the stat is probably not needed?

gaearon · 2017-04-15T12:36:16Z

src/isomorphic/classic/element/ReactElement.js

+        enumerable: false,
+        writable: false,
+        value: owner,
+      });


Can you verify with @sebmarkbage he has no concerns here?

gaearon · 2017-04-15T12:41:20Z

src/renderers/testing/ReactShallowRenderer.js

+      const tree = this._renderer.toTree();
+      if (tree && tree.rendered) {
+        // If we created a context-wrapper then skip over it.
+        const element = tree.type.childContextTypes


This seems fragile. What if it isn't our context but the root element just happens to be a context provider?

To be honest I'm not a fan of second undocumented context argument. Our other APIs don't take it. I think it's remaining from the time context was owner-based and we might as well deprecate it and tell people to use their own context providers explicitly. But it's probably annoying to do in this PR.

Let's just be stricter with checking here.

gaearon · 2017-04-15T12:41:58Z

src/renderers/testing/ReactShallowRenderer.js

+
+        // Convert the rendered output to a ReactElement.
+        // This supports .toEqual() comparison for test elements.
+        return React.createElement(


Would this re-trigger any validation? Would people see duplicate messages?

This would only re-trigger if the ReactElement returned from the top-level render was a class component with propTypes. In that case, it still wouldn't show a duplicate message because checkPropTypes tracks loggedTypeFailures and avoids re-logging duplicates.

Do you think this is reasonable? Should I look for a way of bypassing checkPropTypes for this case (or some other approach)?

What about the key warning?
It’s probably fine, just making sure you’re aware of this.

Key warning will only log once as well.

Yup, much appreciated for the double check. 😄

gaearon · 2017-04-15T12:42:59Z

src/renderers/testing/ReactShallowRenderer.js

+
+  getRenderOutput() {
+    if (this._renderer) {
+      const tree = this._renderer.toTree();


This will likely make all shallow tests slower. Would be good to measure it on some mid size codebase to check the impact. It might be better to add some way of bailing out if it's too bad.

gaearon · 2017-04-15T12:44:56Z

src/test/ReactTestUtils.js

@@ -12,23 +12,27 @@
 'use strict';



While we're at it can we move src/test to a more appropriate place (considering the package structure)?

gaearon · 2017-04-15T12:46:57Z

src/test/__tests__/ReactTestUtils-test.js

-    class SomeComponent extends React.Component {
-      render() {
+  // Shallow renderer only implemented for Fiber in 16+
+  if (ReactDOMFeatureFlags.useFiber) {


I'm a bit confused by this comment. Can we branch on require instead? Otherwise it looks like we stopped testing shallow renderer in Stack at all. However the Stack version is what we're currently running in www.

Otherwise it looks like we stopped testing shallow renderer in Stack at all.

This new shallow renderer is fiber only. Seemed like too much effort to create a new one that supports stack and works with our new bundles- just to throw it away. (I mentioned this in the description but maybe it wasn't prominent enough.)

I'm not sure how to address www yet. I'll give it some more thought. 😄

Oh. I didn't realize we deleted the Stack based one. Our usual strategy is to keep both until we’ve migrated everything that uses the old one (e.g. www). This lets us revert to using the old one if the new one has issues. Otherwise once this is merged, we have no way but to fix forward. Which might be fine, but it’s blocking any future syncs, and I don’t know if this will pass www tests or not.

Usually we keep both, and let the tests pick the right one based on the flag.

Yeah, totally understood- and I'm glad you bought it up. I'll figure out a strategy for www tests with stack once the fiber bundles and renderer is solid. 😁

gaearon · 2017-04-16T00:59:46Z

I am also concerned that running toTree() will also make shallow rendering more fragile. For example imagine a leaf component changes to throw in render(). Now your grandparent shallow rendering test fails even though it's meant to be isolated. Am I missing something here?

bvaughn · 2017-04-16T02:59:39Z

Great point Dan.

I just realized something silly anyway 😐 The new renderer actually causes render to be called on the full tree because of how the reconciler works. I need to think about this a bit more.

I'll also add a test to verify that the shallow renderer is...shallow. This is embarrassing. 😅

gaearon · 2017-04-16T11:29:33Z

Yea, this is what I meant by the "bailout" in the comment above. The original PR by @lelandrichardson contained this logic in a more generic way (it allowed "redirecting" types) and I think @sebmarkbage had a strategy for using this for shallow renderer in #8931 (comment). This way it would only render one level deep.

bvaughn · 2017-04-16T15:28:37Z

Gotcha! Thanks for pointers. 😄

bvaughn · 2017-04-17T18:41:47Z

Gave this some more thought over the weekend and tried a couple of alternate implementations. One was similar to ReactNoopRenderer but required monkey-patching ReactCurrentOwner to work which felt too hacky. The other one (which I have now committed+pushed) is stand-alone. I want to do a little more testing to make sure I didn't introduce a regression WRT the lifecycle hooks or something similar- but I feel this route is probably better than the previous test-renderer-based approach.

bvaughn · 2017-04-17T22:44:17Z

I ran shallow renderer tests in www against the new ShallowRenderer. There aren't that many of them unfortunately (only 64) but all pass except:

OCCreditCardForm-test.react.js which uses Enzyme.
P2PMemoField.react-test.js which uses internals (renderer._instance._instance). I'll fix this later as part of syncing the new shallow renderer to www.
P2PProductItemChatThreadBanner.react-test.js which uses ReactLayeredComponentMixin_DEPRECATED. Specifically this one fails because it calls ReactDOM.renderSubtreeIntoContainer which errors because ReactInstanceMap doesn't contain the shallow instance. I think it's reasonable to not support this test with the new renderer- particularly since we were hoping to decouple the shallow renderer from DOM.

I also tried plugging the new renderer into a local copy of Enzyme but didn't spend much time on it once I realized there was some internal coupling (eg ShallowWrapper.instance = () => this.renderer._instance ? this.renderer._instance._instance : null). I believe the Enzyme team has plans to implement their own, Enzyme-compatible shallow renderer for the next major version so I think it's okay to leave this off for now.

In the meanwhile I've reached out to Leland and made him aware of some of the issues I noticed. I think he's going to take a look at this branch and we'll chat some more about it.

Files now import directly from prop-types/checkPropTypes

* Moved test-utils into react-dom package * Added test-utils to package.json 'files' list * Added ReactTestUtilsFBEntry module (though it doesn't really do anything at the moment) * Replaced ReactDOM references with react-dom to avoid duplicating code

…ific entry point. Throw explicit error if imported in prod mode

bvaughn · 2017-04-18T18:32:20Z

(e.g. would be good to run this against at least a few third party projects that use shallow rendering)

All 617 Enzyme unit tests pass for react/react-dom 15 + the new shallow renderer if I make the following patch:

diff --git a/src/ShallowWrapper.js b/src/ShallowWrapper.js
index bd23106..ade4e73 100644
--- a/src/ShallowWrapper.js
+++ b/src/ShallowWrapper.js
@@ -194,7 +194,11 @@ class ShallowWrapper {
     if (this.root !== this) {
       throw new Error('ShallowWrapper::instance() can only be called on the root');
     }
-    return this.renderer._instance ? this.renderer._instance._instance : null;
+    const instance = this.renderer._instance;
+
+    return instance && instance._instance
+      ? instance._instance
+      : instance;
   }
 
   /**

The above patch accounts for the fact that we no longer auto-wrap functional components in a class component.

Enzyme isn't compatible with React 16 yet because there are a lot of hooks into internals. But this improves my confidence about the new shallow renderer and its backwards compatibility (at least from an external POV).

Don't require subclass constructors to pass this along to super

gaearon · 2017-04-18T23:11:28Z

To be clear I don't think it's as important that Enzyme's own tests pass (which may rely on internals too much) since it's bound for major anyway. But we should test it on large projects using shallow rendering (via Enzyme or not).

bvaughn · 2017-04-18T23:13:45Z

Uh, right. But Enzyme's own tests seem like a pretty useful metric given their volume. If the new renderer passes all of their tests- that's a good sign, no?

I'm having trouble testing it on projects using shallow renderer because none of them have updated to be React 16 compatible yet.

koba04 · 2017-04-19T01:20:31Z

What do you think ShallowRender has a new API like getPublicInstance, which returns a public instance?
Currently, Enzyme depends on React internal to get a public instance.

https://github.com/airbnb/enzyme/blob/master/src/ShallowWrapper.js#L197

It would be nice if it is accomplished without depending on React internals.
To do that, Enzyme needs some works because Enzyme is using a public instance even if it's a Stateless Functional Components, but it can be fixed.

bvaughn · 2017-04-19T02:16:24Z

What do you think ShallowRender has a new API like getPublicInstance, which returns a public instance? Currently, Enzyme depends on React internal...

Yeah, I had to patch ShallowWrapper to test it with the new shallow renderer. :grimace:

AirBnb has plans to rewrite Enzyme internals for the next release though. The idea is for libraries like React (and similar ones- Preact, Inferno, etc) to provide an abstraction layer / adapter that Enzyme consumes rather than reaching into internals. The Enzyme team can then create adapters on their side (eg one for each major version of React) so their core can be cleaned up. (This file has since been deleted, or maybe moved, but I think it explains the general idea.)

That's a bit orthogonal to this PR though probably. At the moment, I don't think they have any plans of actually using this new shallow renderer. It's for non-Enzyme users (including Facebook's non-Enzyme tests).

bvaughn · 2017-04-19T03:06:18Z

By the way, Dan- thanks for the unblock approval. I'm going to spend a little more time walking through the 30 failing tests in www and writing down the reasons why they're failing (patching things up if possible) to make our later sync easier. I hope to merge this PR sometime tomorrow.

… test vars to const/let

gaearon · 2017-04-19T10:27:07Z

Sounds great!

bvaughn · 2017-04-19T22:41:25Z

All www tests pass now! Added a few more tests for edge-cases I found while running through www tests. Soon as Circle gives it a green check, I'll merge.

bvaughn · 2017-04-19T22:47:47Z

For posterity (or future-me) here's the list of mods I made in www while testing:

Add 'prop-types' and 'create-react-class' packages to html/shared/node_modules
Add magicdirs entries for the new bundles and the above NPM packages so Haste could find them.
Patch Enzyme's ShallowWrapper.instance() slightly to account for the fact that the new renderer doesn't wrap function components in a class component.
Noop mock unstable_renderSubtreeIntoContainer since any calls to this method would fail due to dependencies on ReactInstanceMap which isn't used by the new shallow renderer. (This was required for tests like P2PProductItemChatThreadBanner.react-test.js that use ReactLayeredComponentMixin_DEPRECATED.)
Updated ReactDOMServerStack-dev to read checkPropTypes from prop-types/checkPropTypes rather than React.checkPropTypes. (Enzyme invokes this using renderToStaticString.) Also updated ReactARTStack-dev in a similar fashion.
Replaced renderer._instance._instance with renderer.getMountedInstance() in P2PMemoField.react-test
Mock XControllerURIBuilder.prototype.setInt.mockReturnThis() for TestConsoleLoader-test.react.js

I'll submit a WIP diff for the above changes internally as well for when we eventually sync a newer alpha to www.

koba04 · 2017-04-20T00:35:49Z

Great work! 🎉

bvaughn · 2017-04-20T01:49:28Z

Thanks so much for the helpful info you provided @koba04 !

gaearon · 2017-04-20T09:08:51Z

Great work!

oguzgelal

Whoops, meant to add a single line comment

oguzgelal · 2017-11-04T15:13:24Z

packages/react-test-renderer/shallow.js

+
+if (process.env.NODE_ENV === 'production') {
+  throw Error('shallow renderer is not available in production mode.');
+} else {


@gaearon @bvaughn I'm having a problem with these lines: I'm using enzyme and it uses shallow rendering, for tests, while NODE_ENV is set to production. So my tests are failing because of this.

gaearon · 2017-11-04T15:26:40Z

I added prod builds in 16.1. You can try 16.1.0-beta now.

oguzgelal · 2017-11-04T15:36:29Z

Hmm. Upgraded to 16.1.0-beta but still having the issue.

gaearon · 2017-11-04T15:39:11Z

This code doesn't exist in it.

https://unpkg.com/[email protected]/shallow.js

If you still see the issue you have not upgraded. Or forgot to update some packages.

oguzgelal · 2017-11-04T15:41:36Z

Ah you're right, yes I updated react not react-test-renderer. Thanks!

Shallow renderer and test utils bundles Adds new bundles introduced with React 15.5 release to master (and 16 alpha) react-dom/test-utils: This new bundle contains what used to be react-addons-test-utils. This bundle shares things from react-dom rather than duplicates them. A temporary createRenderer method has been left behind as a way to access the new shallow renderer. This is for the ReactNative release cycle only and should be going away before the final release. react-test-renderer/shallow: This new shallow renderer is almost entirely stand-alone (in that it doesn't use the React reconciler or scheduler). The only touch points are ReactElement and prop/context validation. This renderer is stack and fiber compatible.

facebook-github-bot added the CLA Signed label Apr 14, 2017

bvaughn changed the title ~~New (fiber-only) shallow renderer~~ New (fiber-only) shallow renderer [WIP] Apr 14, 2017

This was referenced Apr 14, 2017

[Fiber][WIP] Shallow Renderer #8808

Closed

Add createComponentMock option to test renderer #8982

Closed

bvaughn force-pushed the react-dom-test-utils-shallow-renderer branch 3 times, most recently from d98cfee to fb05fc9 Compare April 14, 2017 17:22

gaearon reviewed Apr 14, 2017

View reviewed changes

bvaughn force-pushed the react-dom-test-utils-shallow-renderer branch from a5b7aff to b8c35d8 Compare April 14, 2017 20:25

bvaughn changed the base branch from react-dom-test-utils to master April 14, 2017 22:19

bvaughn mentioned this pull request Apr 14, 2017

Added react-dom/test-utils bundle #9414

Closed

bvaughn changed the title ~~New (fiber-only) shallow renderer [WIP]~~ Shallow renderer and test utils bundles Apr 14, 2017

bvaughn requested review from sophiebits, sebmarkbage and trueadm April 14, 2017 22:38

gaearon reviewed Apr 15, 2017

View reviewed changes

bvaughn changed the title ~~Shallow renderer and test utils bundles~~ Shallow renderer and test utils bundles [WIP] Apr 16, 2017

bvaughn force-pushed the react-dom-test-utils-shallow-renderer branch from bef9f05 to 86bfb52 Compare April 17, 2017 18:37

bvaughn changed the title ~~Shallow renderer and test utils bundles [WIP]~~ Shallow renderer and test utils bundles Apr 17, 2017

Brian Vaughn added 4 commits April 17, 2017 22:45

Added react-dom/test-utils target

02129cb

Removed level of indirection for checkPropTypes

a3e4d67

Files now import directly from prop-types/checkPropTypes

Cleaned up test-utils bundle slightly by removing unnecessary fb-spec…

e9f542f

…ific entry point. Throw explicit error if imported in prod mode

Explicitly set instance.updater after construction

35ae167

Don't require subclass constructors to pass this along to super

Updated lifecycles tests and behavior to mirror 15.x shallow renderer

4f15cba

Shallow renderer setState() supports updater function. Also converted…

e8ef8fa

… test vars to const/let

Brian Vaughn added 4 commits April 19, 2017 09:47

Better handle setState() calls from cWM or cWRP

bf0583b

Shallow renderer preserves state for cloned element

fc1c6f9

TestUtils use batchedUpdates from ReactDOM instead of loading separately

50793d4

Updated fiber passing tests

5710088

bvaughn merged commit 66f2097 into master Apr 19, 2017

bvaughn deleted the react-dom-test-utils-shallow-renderer branch April 19, 2017 23:45

nevir mentioned this pull request May 31, 2017

Support all Component Lifecycle methods in ShallowRenderer enzymejs/enzyme#318

Merged

gaearon mentioned this pull request Aug 3, 2017

Don't call componentDidUpdate() in shallow renderer #10372

Merged

gaearon mentioned this pull request Nov 3, 2017

Remove support for cloneElement(getMountedInstance()) in shallow renderer #11441

Closed

oguzgelal reviewed Nov 4, 2017

View reviewed changes

Shallow renderer and test utils bundles #9426

Shallow renderer and test utils bundles #9426

Conversation

bvaughn commented Apr 14, 2017 • edited Loading

react-dom/test-utils

react-test-renderer/shallow

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn commented Apr 14, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn Apr 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn Apr 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvaughn Apr 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gaearon commented Apr 16, 2017

bvaughn commented Apr 16, 2017 • edited Loading

gaearon commented Apr 16, 2017 • edited Loading

bvaughn commented Apr 16, 2017

bvaughn commented Apr 17, 2017

bvaughn commented Apr 17, 2017 • edited Loading

bvaughn commented Apr 18, 2017 • edited Loading

gaearon commented Apr 18, 2017

bvaughn commented Apr 18, 2017

koba04 commented Apr 19, 2017

bvaughn commented Apr 19, 2017

bvaughn commented Apr 19, 2017 • edited Loading

gaearon commented Apr 19, 2017

bvaughn commented Apr 19, 2017

bvaughn commented Apr 19, 2017

koba04 commented Apr 20, 2017

bvaughn commented Apr 20, 2017

gaearon commented Apr 20, 2017

oguzgelal left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gaearon commented Nov 4, 2017

oguzgelal commented Nov 4, 2017

gaearon commented Nov 4, 2017

oguzgelal commented Nov 4, 2017

bvaughn commented Apr 14, 2017 •

edited

Loading

bvaughn Apr 15, 2017 •

edited

Loading

bvaughn Apr 16, 2017 •

edited

Loading

bvaughn Apr 15, 2017 •

edited

Loading

bvaughn commented Apr 16, 2017 •

edited

Loading

gaearon commented Apr 16, 2017 •

edited

Loading

bvaughn commented Apr 17, 2017 •

edited

Loading

bvaughn commented Apr 18, 2017 •

edited

Loading

bvaughn commented Apr 19, 2017 •

edited

Loading