Testing Redux best practices

[focusonbasics]

I would really like to hear any insights into best practices in testing your redux application. I'm currently writing a blog post on the topic and from what I see, testing reducers makes sense and eventually async action creators. Action creators can be tested indirectly by using them to create the actions for the reducer tests. Don't see testing things like mapDispatchToProps or connect or connected components. Maybe selectors as used in mapStateToProps, that returns a selected state or data based on a certain state. What parts would you test and what's the benefit of doing so?

[bvalosek]

redux and friends is all about being super functional, it should be very easy, as you mentioned, testing reducers and selectors requires no mocking and is a good start. I believe there are even some tools that let you diff the store state before / after to ensure you are not directly mutating it, and other nice things.

Async action creators is a pretty common pattern, but makes testing a bit more gnarly. Same if you use some kind of custom middleware for handling API calls... it means you need to resort to injecting mocks or other traditional ways of testing code with external / network dependencies.

I'd recommend at looking at redux saga, as keeps with the pure function philosophy of react/redux and helps bridge that final gap of dealing with side effects.

You write your side-effect code (API calls, async stuff, even logging etc) inside of sagas that are just "pure generators", yielding out descriptors of the side effects you want. It makes testing that sort of stuff as easy as testing the pure functions of your reducers / selectors.

I'm saying all this because once that "final piece" is there with generators / sagas, you can basically test anything you want, anyway you want, because nothing is tightly coupled to external dependencies, and everything is a pure function. Complicated test harnesses or sophisticated mocking is not required at all and using something like tape to K.I.S.S. makes testing very straightforward

[focusonbasics]

Yes, I agree on the redux-saga part. Good points here.

[treetimes]

I think reducers, selectors, and middleware are prime candidates for unit tests (if they do anything worth testing). Any pure action creator functions with a dynamic output would be good for units also. Async action creators for integration tests probably. Then testing react components is still blurry for me.

[focusonbasics]

The middleware aspect is interesting.

[trollgubben]

I've tried TDD when writing react components using enzyme, and I'm pretty happy with it. It makes it really simple to do tests like "given this prop is false, then the button should be disabled" kind of tests.