Add notes for May 5

[gaearon]

Feel free to discuss in this PR!

[glenjamin]

What would it mean to become the "official" test utils?

There is more than one test helpers lib out there, blessing a single one would be a bit harsh on the others.

I'd be in favour of trimming down TestUtils functions and linking to a community list of tools which build on top of it.

[gaearon]

It would mean that Enzyme is linked to in the documentation and we tell people to use it rather than to scryRenderedComponentsOfType. For us, it would also mean no longer shipping the TestUtils as we don’t use them that much at Facebook.

Whether either of this is something we want to do, or not, is unclear.

[glenjamin]

I think having core provide testing primitives and leaving userland to layer on top is a good thing, but I'd be wary of recommending only a single lib.

[gaearon]

This is one of the reasons why there is no decision on this yet. It's a tricky balance. “Testing primitives” is also vague: we do provide them today (TestUtils) but we are not sure that this is the primitives we want to expose. As noted in text, we’d rather see test runner as a custom React renderer. In this version of the future, React does not need to expose any hooks at all because the custom renderer has full control over components. This is probably where we want to go but the obstacle is we don't have a public API for renderers, and the internal APIs will be changing because of the work on incremental reconciler. Therefore writing custom renderers will be turbulent in the coming months. This was the reason React Native renderer code was pulled into React codebase—to allow faster iteration on the internals.

So none of this is clear yet. While TestUtils exist the way they do today, it doesn’t quite make sense to tell people to use something else yet. However in the future, it might make sense for Enzyme to become more tightly coupled with implementation details of React, at least until the renderer API shakes out. If this happens, and it gives us a way to deprecate TestUtils in the future, we’ll likely need to point to something—and I would expect that it’s likely we won’t have other test renderers at that point because creating a renderer right now is somewhat brittle and requires quite a bit of effort. In that case, maybe, recommending Enzyme officially might be sensible.

But we don’t know much yet. These are just thoughts aloud. We are talking through different options and did not choose any particular strategy.

[glenjamin]

I'd like to see the shallow rendering capability remain a part of core react - whether that's a custom renderer or not shouldn't make a lot of difference to a consumer.

Enzyme's main utility is in replacing the find/scry methods with ones which work consistently when rendering to DOM, String or Shallow. Having that library be the only place where a shallow renderer exists would be disappointing.

If moving the shallow rendering code out of core is a goal, hopefully the community (myself included) will find a way to keep it decoupled from the test assertion / node traversal stuff.

I hadn't realised enzyme was already prominently featured on the TestUtils docs page. This is a bit disappointing to me, as although I have nothing against enzyme, it pretty much kills any hope similar libraries have of getting takeup when exploring that space.

Anyway, to summarise my thoughts on this:

• 👍 deprecate (find|scry)*
• 👎 moving shallow rendering out to enzyme
• 😑 moving shallow rendering out to userland

This is driven from the fact I have a shallow-rendering based testing lib which is a couple of months older than enzyme and has ~40% of the monthly npm download numbers enzyme does. I'd like to see even more competition / exploration in this space, and having core bless a particular lib could stifle that.