Improve documentation on unit testing redux components

[c089]

I've noticed that the Writing Tests page explains how to unit test react components, but doesn't really go into details / show examples for containers wrapped by redux. I believe that unit testing vanilla JS components should rather be documented in the react documentation instead and redux docs should show users how to test components that are connected to redux.

My personal approach to this is to use shallow rendering and assert on the props of the wrapped component, so that I test the logic in mapStateToProps in one unit test and have independent unit tests for the wrapped components (if at all, as they often end up being static markup with no logic).

I'm happy to work on a PR for this but want to get some opinions before starting that.

[mxstbr]

👍 I've run into this and have to yet to find an elegant solution on how to test mapStateToProps and mapDispatchToProps. I'd love if there was an official guide for that, though I think we can let the explanation on how to test non-connected components in there too.

[gaearon]

I don’t have definitive opinions on this. I think mapStateToProps is best defined outside components (like “selectors” in reducers folder of shopping-cart example). Then you can test that the selector returns expected state as you apply reducer after several actions without actually relying on the state shape itself.

However I’m open to other suggestions from people with experience of testing container components themselves.

[c089]

👍 I've thought about testing the selectors independent of their containers before as that massively simplifies the tests (plain JS in, plain JS out \o/) for those but was unsure because most documentation seems to keep them inside the containers and not assign them their own name (I like "selectors". fluxible uses "views" in their reducer store reference but that word is horribly overused).

[gaearon]

Documentation doesn’t use them because selectors were not as popular at the time of writing the documentation.

[c089]

So should we rather update documentation to include that concept instead of documenting testing them integrated with react? I'd like that because redux is not really tied to react anyway...

[c089]

This tip from @gaearon hints in the same direction: move selectors out of the container and keep them close to the reducer.

Also for the record I was wrong about fluxible using "views" for that before, they use "getters" (but still follow the same pattern of keeping them together with the reducers, see docs).

[gaearon]

Redux is not tied to React but practically speaking most Redux users are React users, React is used in the docs anyway, and testing isn’t that much different for different view libraries.

We should amend the docs to include different techniques but we shouldn’t remove useful parts just because they are React-specific. People are going to come to issues and ask anyway. Rather, we should improve those parts as well with more specific instructions, but at this point I can’t give recommendations—if you have experience, you tell me how to best test container components 😄

[fdecampredon]

One of the thing that I end doing a lot is exporting the different part of the component as named export, and the final component as default, this way I can easily test the different part separately :

export const maspStateToProps = (....) => {
 ...
} 

export const mapDispatchToProps = (...) => {
  ...
}

export class MyComponenent extends React.Component {
  ...
}

export default connect(mapStateToProps, mapDispatchToProps)(MyComponent);

I'm not really happy with this since I think that exporting private parts of a module just for the sake of testing is a bad habit.
But It often becomes too much a pain to test the whole logic just from the the final component.

[fshowalter]

I came to the same solution as @fdecampredon.

It's pragmatic. You test mapStateToProps to verify your shaped state. If you're reaching into another bit of shared state and that node's name changes, your test will break and tell you. You test mapActionCreatorsToProps to verify you don't have any typos in your imports. 😄

You trust connect to work as advertised.

The extra exports don't bother me, as no one familiar with react-redux will mistake them for an exposed component API.

[c089]

I'm not really happy with this since I think that exporting private parts of a module just for the sake of testing is a bad habit.

👍

You trust connect to work as advertised.

👍

I think if we have selectors tested separately in the reducers, we can combine both of those good patterns: connect will receieve a minimal mapDispatchToProps that only calls the selectors that are already tested.

[dmitry-zaets]

Currently Our team also ended up with exporting mapStateToProps and mapDispatchToProps only for test purposes. This looks not really handy and we've been thinking to separate them into new file which placed near smart component, something like:

• MyComponent folder
  • index.js (contains simply export default connect ...)
  • map.js or mapping.js (maspStateToProps and mapDispatchToProps)
  • MyComponent.js (React component)

[dmitry-zaets]

Also we've faced issue with testing async action creators, would be good to cover more complex cases in documentation as well.

[Phoenixmatrix]

I'm leaning torward one of two ways.

A) A 'perfect' world would be: given a mock store, and stubbing out the connected component, run assertions on the props of the stub component to match what I'd expect. That way mapStateToProp/mapDispatchToProp could stay private and it doesn't matter. They obviously also could be public if it makes sense and you could test them separately or stub them.

B) externalize/export mapStateToProp/mapDispatchToProp/selectors and test them separately. Assume that the call to connect is correct and don't test it.

B is drastically easier, but there's room for mistakes, bugs and untested glue. Plus you may be making public stuff you normally wouldn't purely for testing purpose. A could be made easier with some utilities (which isn't a bad thing. redux-mock-store is a utility that makes testing async creators much easier, and I don't see that as wrong).

I need to try out more real world scenarios to make up my mind, personally.

[weicheng113]

Hi Guys, how about the approach here #1458, which covers some area. This is a known practice used in OOP world.

Cheers, Cheng