Potential issues with `store` as a prop and shallow test rendering in v6

[markerikson]

I've seen a few different reports related to this topic, so I'm going to open up this issue for discussion.

In React-Redux v6, we removed the ability to pass the store as a prop named store directly to connected components. (See my post explaining why this change was made.)

Generally, the only meaningful use case I knew of for this capability was for unit testing, as some people passed a store directly as a prop instead of wrapping the component in a <Provider>.

I've seen some complaints that Enzyme's shallow() does not work well with putting a <Provider> around a connected component, but I'm not clear on the details of what exactly breaks.

Is it that Enzyme still does not support React's createContext correctly? That rendering shallow(<Provider store={store}><ConnectedComponent /></Provider>) does not actually generate any output from <ConnectedComponent />? Something else?

As a related question, what exactly does it mean to "shallow-render a connected component"? What do tests with this approach look like, particularly in terms of Enzyme API usage and assertions?

I'd appreciate some examples of tests that are having issues, explanations of what specifically is breaking (beyond just "I can't pass the store as a prop any more"), and any further details people can provide related to this issue.

[dschinkel]

One of the biggest problems I have with React and Redux lately is that they are slowly both forcing everyone down the path of using the Context API without considering backward compatibility for isolated tests specifically with the most popular lib used still which is enzyme. All along React's and Redux's API was simple enough to where you could do simple things with it through shallow. That's no longer the case as this API evolves...and those who have happily and effectively written tests this way are having to come back and let you folks know about it when I think these uses cases should have already been found and part of React and Redux release testing.

By using the Context API that requires you to use mount() because you simply can no longer do easy things to components such as shallow. Redux 6 shut off the ability to pass in fake stores as props. All my past tests will break if we upgrade. Do I want my clients to sit on v5 for the next 5 years? I guess they could or we would have to rewrite the application (worse). Both situations are bad for the users of Redux and React in both scenarios; Wouldn't it be better would be if React and Redux would allow us to continue to write isolated tests easily as we've been able to do for the past 3-4 years by not restricting the API or changing it in a way that would prevent test simplicity?

I personally don't like using provider in my tests, it's huge bloat. It's been completely necessary the way I code react applications...unless you're writing integration tests. That's the thing, the React team seems to mainly just promote integration testing which is another beef I've had with that "framework". I cannot call this a lib anymore.

What if there are those who don't want to use contextAPI for persistence and actually are fine with passing state as props and find that route "simplistic" regardless of the "inconvenience".

The problem I see is that the way React and Redux are moving, they're continually changing the API in a way that undermines the ability to shallow and IMO they don't really care because they would have already noticed that enzyme shallow is breaking due to their major API changes. They're not backward compatible anymore, new react features are literally breaking things and they don't care about isolated tests IMO generally which is my general take on it because if they did they'd already have seen this issue before releasing such major changes to their API.

It's fundamental to be able to shallow components. That's what made react and redux so great in the beginning. VueJS still has that ability in fact it's built right into their testing lib.

On the point of TDD: I'm not saying you have to TDD. But those who do, we just want to be able to continue building these apps and test them in the same way we've always been able to. To shut off simple DI like that and to force people down paths that literally kill shallow to me is just not a very good move by React or Redux. The fact is if the React and Redux teams themselves wrote isolated tests more using enzyme shallow, they would have already seen this pain.

What if we're not using createContext() and we still want to shallow test components and DI other ways through our isolated tests? Then we don't use Redux anymore. Well that kinds sucks because if Redux 6 already allowed us to shallow easily and inject the store still, this wouldn't even be an issue for those who test using shallow without provider.

But even after that, lets say we don't use Redux anymore after that pain. React still is a barrier/concern because for example recently hooks, you can't shallow render hooks. Another TDD'ist I know ranted on not being able to shallow render hooks. Sure we can put in an issue but shouldn't the React team already figure that there are people who are going to want to shallow render still with "new stuff"?

I would like to think that at the least, the React and Redux team at least considers testing enzyme shallow and mount both, not just mount when they release stuff. They should find that hey, if we change the API this way, it might be good, but we might prevent the ability to shallow render with enzyme's existing lib, something they've been able to do all along. Or they should say hey, if we remove the ability to inject stuff simply as props, it's going to affect shallow tests in x way. The use cases are pretty simple on the enzyme side, you showed one already @markerikson

I don't have time to write a huge blog post on this at the moment @markerikso. There are tons of articles that have been out there for years on shallow rendering React or Redux and passing in the store as a prop. Those are plenty of use cases IMO.

[markerikson]

So as I see it, there's a few general / potential issues here overall:

• React's shallow test renderer does not appear to support the new context API
• Enzyme itself does not yet meaningfully support the new context API
• React-Redux's internal changes required removing the ability to pass the store as a prop. Note that this was specifically because individual components no longer subscribe to the store directly.

I think it's also important to note that both Enzyme and React-Redux are separate libraries and not controlled by the React team. Also, the React team does not, as far as I know, directly promote the use of Enzyme for testing.

@dschinkel , you've written a lot of words there. I appreciate that you actually more reasonably addressed this issue, but you're still primarily talking in generalities. It would help if you could specifically address the questions I've asked, provide some concrete examples of tests that you've written, and offer up some actual potential solutions (beyond just "bring back store-as-prop").

In other words: what things are you trying to assert in these tests? What capabilities do you need - just passing in a particular state to render the component's output?

As my mom said to me many times when I was growing up: "You've stated the problem. Now state the solution". :)

I'm also confused why "using Provider in my test is huge bloat".

[dschinkel]

Here's the thing, I don't agree that this is all on the enzyme lib. You can evolve React or Redux in a way that's more backward compatible that supports testing components shallowly naturally so it makes any testing library now or in the future able to do that with simplicity. What if I use something other than enzyme? We're going to want to shallow test. But by closing of the API for certain DI routes, you automatically prevent that for any lib going forward.

I'm also confused why "using Provider in my test is huge bloat".

1) provider is really meant for cases where you want to persist state down not just the component under test but also its children. When I write isolated tests I don't care about rendering children or passing state down to their render
2) For test simplicity and readability. I've found that provider is completely necessary especially when our tests are very focused on testing certain behavior in the immediate component under test. I don't want to have to wrap things constantly in provider and have yet another object to deal with that's a black box like providers is. I send in fake stores to my components via a prop. It's not reliant on provider, and that's a huge plus to isolated testing.

[minznerjosh]

@dschinkel I hear you. Having worked with angular a lot before react, I missed the fact that testing experience was one of the cornerstones of the framework. I definitely got the impression that it wasn't the biggest priority in the react ecosystem. (Not complaining, there are always tradeoffs!)

Regarding hooks, that's still a pre-release feature. I don't remember where I read it, but I do remember reading that it won't become fully released until shallow rendering support is added.

And, with regards to the createContext() API, @ljharb and I (mostly him) have come up with an API in enzymejs/enzyme#1960 that will allow both mount()ed and shallow()ed components to be given the context they need to render. Obviously the PR is still open and in progress, but I'm confident that, even if that particular API doesn't make it in, another will.

I realize your frustrations are bigger than this particular issue, but support for these new features is coming to enzyme, and hopefully sooner rather than later.

[minznerjosh]

@markerikson FWIW, react actually does plug enzyme in their shallow render docs: https://reactjs.org/docs/shallow-renderer.html

[dschinkel]

I'm sorry I sound like a jerk. It's just a big issue for use who have really come to enjoy TDD'ing React and Redux for all this to just change and prevent us from ultimately using shallow and writing isolated tests in very very simple ways. I guess I feel like this should have already been caught by both teams and I guess I have the feeling that with all the focus on integration tests i see with the React team, that they don't care. Prove me wrong, I'd love to be proven wrong on that last part.

To be fair, I promised mark a blog post but I just have not had the time.

@minznerjosh

FWIW, react actually does plug enzyme in their shallow render docs:

Right! Keep in mind a lot of us have used React for over 4 years now as well as Redux. In the beginning both were very much aware of the value of shallow testing early on. But feel they're losing that focus due to focus only on integration test support. And the lack of both not understanding these use cases already I guess bothers me to some degree. Just being honest.

And, with regards to the createContext() API, @ljharb and I (mostly him) have come up with an API in enzymejs/enzyme#1960 that will allow both mount()ed and shallow()ed components to be given the context they need to render. Obviously the PR is still open and in progress, but I'm confident that, even if that particular API doesn't make it in, another will.

And I appreciate it @minznerjosh

The fact is a lot of us are consultants. A lot of us practice TDD (or not) and quite a few of us write a lot of isolated tests and through React found awesome simple ways to do so with shallow. So if I go to a client, I want to be able to both take them where they're at AND show them a better way. If they're using mount all the time but we've found a great way to test via shallow and have always been able to, if a client is on React version x and Redux version y, I'd like to know that we can still count on at least React and Redux teams to try to keep the framework's API changing in a way that's easily tested using shallow and that we don't have to keep worrying about this going forward.

It would help if you could specifically address the questions I've asked, provide some concrete examples of tests that you've written, and offer up some actual potential solutions (beyond just "bring back store-as-prop")

Yea. Will when I find the time. Glad you started this thread. You're the only one who has really addressed it at this point.

[markerikson]

@dschinkel : I know you have very strong opinions on these issues. I want to keep those out of this discussion as much as possible.

I'd like to focus specifically on technical aspects of the React-Redux API. Don't use the word "TDD". Don't complain about how React is changing, or how you feel like they "don't care" about the ecosystem.

Tell me what specific technical needs you have, and hopefully we can come up with some solutions that help everybody.

[dschinkel]

TDD is part of context here and largely why I feel both teams are unaware of these use cases TBH.

Isolated tests is part of context independent of TDD but understanding use cases for either case, and that there are quite a few devs that test via shallow because of TDD's approach to design feedback and evolving a feature is why I mentioned it. I feel there's a lack of realizing that there is a pretty large group out there who write shallow tests because of that.

We can take out TDD from my rants above. Just replace it with "shallow testing". Simple.

[markerikson]

I know, and I'm saying that phrase is irrelevant to the discussion. I don't care what conceptual approach you're using to write your tests. I want to know what technical problems you're encountering because of "store-as-prop" being removed, and the other changes in v6, besides the obvious literal "this breaking change broke my code" aspect.

[ljharb]

I hope for enzyme to have createContext support soon, but I’d urge you not to drop < 16.3 compat lightly. yes, enzyme is basically the officially endorsed testing solution at the moment, although that could always change if we don’t catch up to React’s feature set quickly enough :-)

I do also hope to have a general solution soon in enzyme that works ergonomically for provider-like components (both createContext Providers, and the incredibly common Provider component pattern, as well as components with lifecycle methods to set up state). Once that exists, it might not be as big of an issue for libraries to make this sort of change.

In other words, ofc do what you like with your library, but here are some thoughts i hope are helpful:

1. enzyme will continue to strive to make it easy and ergonomic to use every React feature, and also/separately, every common community pattern, unrelated to my personal opinion on it (eg: i abhor render props as a bastardization of jsx, but enzyme now has a .renderProp API to make working with them easier, and supporting this workflow is a priority whether it’s my favorite or not) This includes the Provider-like support i alluded to above.
2. it can be very user-hostile to aggressively drop support for older platforms (node/browser engines), frameworks (React versions), or patterns (props over context). It would be really pleasant for users of redux if they could continue to use up to date versions of the library without being forced to upgrade node, drop browsers from support, upgrade react, or rewrite their code. It’s also important for redux maintainers to have a pleasant experience maintaining the library, and these concerns often collide. Of course, make the decision you feel is best for your library, but hopefully also for your users :-)

If there’s something enzyme can do that isn’t already being worked on, please do file an issue and I’ll do my best to help find a good solution!

[markerikson]

React-Redux v6 already dropped compat for <= 16.3. We have a minimum peer dependency of 16.4. 16.3 is the minimum for use of createContext, and 16.4 brought in the fixes for getDerivedStateFromProps. (We wound up not needing to use gDSFP ourselves, but if you're on 16.3, there's no reason not to be on 16.4.)

In general, if you need to stay on React <= 16.3, v5 still works just fine.

I will say that some of Sebastian's comments in facebook/react#14110 suggest that perhaps the new context API isn't as ideal as it has been described, particularly with the way React-Redux uses it. Having said that, we still had plenty of good reasons to switch to using it this way in v6, as I described in my blog post, and the removal of "store-as-prop" is a direct technical result of that change.

[markerikson]

@dschinkel : I've got free time over the next couple days and can put some attention into this. What I need from you is several actual tests that run under v5, but not under v6, including components. I don't care how "real" the components are, I just need all the actual code for the tests to really run.

I'm particularly interested in how you are setting up the store, and what you are asserting.

Ideally, I'd love to have a link to an actual repo that I can just clone , install, and run the tests. Failing that, I'd settle for a complete tests file in a gist.

I do want to help, especially since there seem to be others dealing with this issue as well, but I need you to give me the resources to investigate so I can figure out options.

[dschinkel]

Ok thanks Mark, I'll put something up by end of the day or early Sunday. Today I'm busy until the afternoon then I'll find some time tonight.

[markerikson]

Playing around a bit with a sandbox provided by @BTMPL .

Unfortunately, as best as I can tell, shallow() simply does not call a Context.Consumer's render callback. Dan pointed out that React's shallow renderer is incredibly simplistic. It seems like the first blocking issue here is that the shallow renderer at least needs to have some specific support for handling context consumers.