4 ms·
> it's hard to test (despite what the documentation claims). It's highly declarative, and such code seems hard to test. redux-saga member here. If we concede
by qudat 4y ago
> it's hard to test (despite what the documentation claims). It's highly declarative, and such code seems hard to test.
redux-saga member here. If we concede that mocks are inherently difficult to get right and maintain, often requiring libraries or testing frameworks to do a lot of the heavy lifting, then I would argue testing sagas is a breeze in comparison.
The real magic behind redux-saga and its use of generators is the end-user functions do not have side-effects at all, they merely describe what those side-effects ought to look like. The library activates the side-effects in its runtime, the end-user just yields to json objects.
So in order to test sagas, all you need is to run the generator and make sure it yields the things you expect it to yield.
https://bower.sh/simplify-testing-async-io-javascript https://bower.sh/simplify-testing-async-io-javascript
Having said all that, because the react world has heavily shifted towards hooks -- which explicitly make the view layer impure and hard to unit test -- a bunch of tooling has come out to prefer integration testing. In particular, testing user flows and evaluating what the user sees. In this paradigm, testing individual sagas or even react components is not nearly as valuable.
- sktrdie 4y agoFirst of all, sagas are an amazing concept that I still cherish even if I don’t use them anymore (hype not there?). Regarding the hooks comment I’m not sure I follow. Surely components are also idempotent (if you skip useEffect) and should be replayable - that’s at least how I think react refresh can manage to keep state intact during file changes in development. Anyway I still very much value the concepts behind sagas so thanks for great work.
- qudat 4y ago> Regarding the hooks comment I’m not sure I follow. Surely components are also idempotent (if you skip useEffect) and should be replayable - that’s at least how I think react refresh can manage to keep state intact during file changes in development. We used to have the concept of smart and dumb components, with dumb components we could test if we provide X props we could determine Y result and write tests expecting Y to be true. Now with the advent of hooks, side-effects are much more likely to be in all of our components. This makes react components impure and difficult to test as individual units. This movement started primarily with the shift to hooks. > Anyway I still very much value the concepts behind sagas so thanks for great work. Thanks!
- the_other 4y ago> redux-saga member here. Thanks for responding! > So in order to test sagas, all you need is to run the generator and make sure it yields the things you expect it to yield. This was the crux of what I found frustrating, actually. A simple saga with one or two steps was ok. Longer ones were painful. My test scripts ended up with these patterns: - looking 80% like my application code - needing to mock almost every step (every yield's output and input) - which bifurcates quickly if your sagas branch - requiring digging into the emitted call/take/etc payloads (which seems the opposite of what you want when using a utility - I'd prefer to "let the utility just do its job" in the tests) - brittle tests - when I changed a saga, I usually needed to change the test, rather than being able to leave the tests alone to prove my refactor works. None of this put me off using redux-sagas. The benefits for the application code were worth it, IMO.
- qudat 4y agoHey thanks for the thoughtful response. I agree with everything you mentioned here. I'd love to continue to chat with you about how to make testing sagas better. If you'd like, it would be great if we could move this convo to https://github.com/redux-saga/redux-saga/discussions/2337 https://github.com/redux-saga/redux-saga/discussions/2337