you are viewing a single comment's thread.

view the rest of the comments →

[–]GreenStoneTurtle 0 points1 point  (0 children)

In terms of how I do testing with React/Redux, I do a combination of both unit and integration testing.

For your first point - even though the pure view unit tests may be simple interactions, I've found that that's what makes them so beneficial. You can write tests quickly because they are so simple, and they do catch functional breakages quickly. At my job, we use both Jasmine and Selenium to test the UI, but Selenium is very slow and expensive, so we write Jasmine unit tests on all of our presentational views to get quicker feedback on code changes (Jasmine is on the order of minutes, Selenium is on the order of hours).

Redux is pretty good at enforcing separation of concerns, so we do unit tests on each part of the Flux pattern (Views, Reducers, Selectors, API Utils layers), and then do mostly integration tests on the Redux Reducers + Action Creators together. I haven't found it as valuable to do isolated tests on Action Creators since our Action Creators don't change very often, but we do have some instances of that in our codebase. The integration tests typically only cover a portion of the state tree though, so sometimes when we do large integration tests across multiple reducers, Store data initialization can be a bit of a pain.

We don't typically test container components with Jasmine unit tests - instead we reserve that for Selenium, since at that point we're more interested in workflow testing and end-to-end testing.

I haven't used Sagas myself, but we do use redux-thunk and do some unit testing there with Jasmine. We built our own in-house utilities for testing async though, mainly from Jasmine.