Can't reference containers wrapped in a Provider or by connect with Enzyme

[mordrax]

I can't seem to reference anything wrapped in a <Provider> and a connect

// test
let component = shallow(<Provider store={store}><ContainerComponent /></Provider>);
component.find('#abc'); // returns null

let component = shallow(<Provider store={store}><div id="abc"></div></Provider>);
component.find('#abc'); // returns the div node

// ContainerComponent
const Component = ({...}) => (<div id="abc"></div>);
export default connect(..., ...)(Component);

I followed: #1481 to the examples where the tests were written with enzyme, however, the containers are never tested in those. So I don't know whether I should/can test smart containers?

@fshowalter Any ideas?

[gaearon]

Neither connect() nor Provider are part of this library. It is easier to discuss and track such issues when they are filed in the appropriate repository instead: https://github.com/reactjs/react-redux.

[markerikson]

I think that actually makes sense. Since you're shallow-rendering, only the Provider component will get rendered - your ContainerComponent will just be left in its object output form or whatever it is shallow rendering produces.

Two thoughts here:

First, note that the wrapper component generated by connect() actually does look for props.store before it looks for context.store, so if you do actually feel like you need to test a connected component, you should be able to render <ConnectedComponent store={myTestStore} /> without needing to worry about Provider or context or anything.

The second question is whether you really need to be worrying about actually testing the fully connected component. The argument I've seen made is that if you can test your "plain" component with specific props, and you can test your mapStateToProps implementation, you can safely assume that react-redux will put them together correctly, and don't need to actually test the connected version itself.

[mordrax]

@gaearon you're right, sorry. Didn't know whether to raise this in react or enzyme repo.

@markerikson Reason for testing smart component is for mapToDispatchProps where I wanted to make sure the right dispatcher was called by the wrapped component. Just passing the store into the ConnectedComponent means I won't be testing the state mapping or dispatch callback functions.

I will think about this more and raise an issue in the relevant repo if I need it. Thanks for the help.

[markerikson]

@Mordra : when you say "right dispatcher was called", do you actually mean "right action creator"?

You could do something like this (syntax is probably off, but you should get the idea):

let actionSpy = sinon.spy();

let wrapper = shallow(<PlainComponent someActionProp={actionSpy} />);
wrapper.find(".triggerActionButton").simulate("click");
expect(actionSpy.calledOnce).to.be.true;
expect(actionSpy.calledWith({type : ACTION_I_WAS_EXPECTING)).to.be.true;

In other words, render your plain component, pass in spies for the props that would have been actions returned from mapDispatch, and trigger whatever behavior the component needs to make it call those actions.

Also, per my earlier comment: you should be able to test your mapStateToProps and mapDispatchToProps separately, and feel safe that React-Redux will call them appropriately, without having to try to test the connected version itself to verify that's the case.

[mordrax]

@markerikson I can't do what you're suggesting because my PlainComponent does not know about actions or action creators. I don't know if this is the right way to do it, but if you look at:
https://github.com/mordra/cotwmtor/blob/master/client/charCreation/charCreation.jsx
you will see that my mapDispatchToProps contains all the logic:

const mapDispatchToProps = (dispatch) => {
  return {
    onCompleted      : (player) => {
      Meteor.call('newGame', player, function (data) {
        console.log('new game return: ' + data);
      });
      dispatch(routeActions.push('/game'));
      dispatch({type: "INIT_GAME", map: generateAreas(), buildings: generateBuildings(dispatch)});
    },
    onCancelled      : () => dispatch(routeActions.push('/')),
    onChangeName     : input => dispatch(actions.changeName(input)),
    onChangeGender   : gender => dispatch(actions.setGender(gender)),
    onSetDifficulty  : lvl => dispatch(actions.setDifficulty(lvl)),
    onChangeAttribute: (attr, val) => dispatch(actions.setAttribute(attr, val))
  }
};

so if I spied on the props passed into the PlainComponent, I wouldn't be able to test whether the right actions are called, but rather, just the parameters passed to the action creators are correct.
I'd then need to test the connect component separately.

[markerikson]

Ah. That helps me understand more.

So with the caveat that I actually have very little practical experience writing tests, a couple thoughts:

• What you actually have there really are action creators, they're just not defined separately because you're wanting access to dispatch. That's not very easily testable in and of itself. You would probably want to be able to test their behavior as well, and to do that you'd want to define them as their own functions outside of mapDispatch.
• Those all look like very good candidates for use with redux-thunk, which would certainly make it easier to define these functions on their own and allow them to access dispatch.
• Your PlainComponent does know about "actions", or at least callbacks in this case, in that you are passing those in, and somewhere in your component you're running this.props.onSetDifficulty("HARD") or something like that. When I suggested passing in spies for actions, this is the kind of thing I was suggesting replacing. So, if you passed in a spy for onSetDifficulty, you could verify that your component called it, and passed in an acceptable value for the difficulty level.

Ultimately, I think you should be able to make things a lot more testable by taking those functions defined in mapDispatch, and define them separately. Then you won't have to worry about having to have mapDispatch hooked up to test your component properly, and can focus on whether or not the component just called a given prop callback with the right arguments or something.

[markerikson]

Also, from the component's point of view: ultimately it's not actually worried about whether {action: CHANGE_NAME, name : "Fred"} got dispatched. All it knows is that it called this.props.onChangeName("Fred"), and that is what you should be trying to test - that it called a prop callback the right way.

[fshowalter]

@Mordra in your case, I would export mapDispatchToProps and test it in isolation. You can verify the property names are all correct and pass a spy for dispatch to test your action creators.

That said, I tend to eschew mapDispatchToProps in favor of mapActionCreatorsToProps which maps already-formed action creators that I can easily test in isolation. In that case I just test that all my props are defined to guard against import typos.

[gaearon]

Finally note that you can use normal (not shallow) rendering. You would need either jsdom or a real browser for that, but then you can render any level deep.

Didn't know whether to raise this in react or enzyme repo

Sorry, I did not mean React or Enzyme repos. I meant React Redux which is the library you are using.

[mordrax]

Thanks for the help guys, that's alot of info for me to go and digest. @markerikson @fshowalter I did some more looking around and will take your suggestion of exporting the mapState/Dispatch and testing them separately, it makes sense to test the callbacks that evoke the expected actions.

@gaearon Stateless component doesn't render without shallow and just skimming the issues, there seems to problems rendering stateful components that has nested stateless components so I've made a mental note to avoid that path for now.

[gaearon]

I'm not sure which issues you are referring to. You can use shallow rendering with functional components just fine. Shallow rendering works only one level deep though (no matter how component is defined). This is its main feature—it doesn't recurse so component tests stay independent. If you have specific issues with shallow rendering that you can reproduce please file bugs against the React repo. Thanks!

[markerikson]

@gaearon : so to clarify, if I do this:

let wrapper = shallow(<A><B /></A>);

will B get rendered, or not? Because I think that's what the original question was - trying to render a <Provider> around a connected component in order to test the connection.