You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to use this thread to discuss new ideas for testing redux-saga. I had a recent chat in hackernews with someone about the difficulties with testing redux-saga and I wanted to bring that conversation here.
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.
saga generator functions perform IO operations without actually activating the side-effects. They will query redux store, make HTTP requests, dispatch actions, or even return data directly. In that sense, they are complicated functions that are not pure. You cannot simply pass a bunch of inputs to the function, see what it returns, and check that it returns what you expect.
Instead, saga functions require us to check every yield to see if it matches what we expect. In that way, they are more integration tests. Because of this, testing a saga necessitates we test the implementation of that saga.
There are libraries that exist that will run the saga and instead of checking to see if each yield matches what we expect, we instead see if the actions it dispatches match what we expect, regardless of order in which those actions are dispatched. This gets us closer, but it's still relatively manual.
To start the discussion, I wonder what new ideas people have for testing sagas? It seems the community has moved more towards integration testing which means that testing sagas specifically are not nearly as useful as they used to be. Should we lean into recommending msw instead? So 80% of the tests could be inside msw and then when we really need to test a saga in isolation we could write a modern guide that leverages one of the libraries above to write it?
I think the result of our discussions here should be an official recommendation for how people test sagas.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'd like to use this thread to discuss new ideas for testing redux-saga. I had a recent chat in hackernews with someone about the difficulties with testing redux-saga and I wanted to bring that conversation here.
https://news.ycombinator.com/item?id=33518012
saga generator functions perform IO operations without actually activating the side-effects. They will query redux store, make HTTP requests, dispatch actions, or even return data directly. In that sense, they are complicated functions that are not pure. You cannot simply pass a bunch of inputs to the function, see what it returns, and check that it returns what you expect.
Instead, saga functions require us to check every
yield
to see if it matches what we expect. In that way, they are more integration tests. Because of this, testing a saga necessitates we test the implementation of that saga.There are libraries that exist that will run the saga and instead of checking to see if each yield matches what we expect, we instead see if the actions it dispatches match what we expect, regardless of order in which those actions are dispatched. This gets us closer, but it's still relatively manual.
discussions:
libraries:
To start the discussion, I wonder what new ideas people have for testing sagas? It seems the community has moved more towards integration testing which means that testing sagas specifically are not nearly as useful as they used to be. Should we lean into recommending
msw
instead? So 80% of the tests could be insidemsw
and then when we really need to test a saga in isolation we could write a modern guide that leverages one of the libraries above to write it?I think the result of our discussions here should be an official recommendation for how people test sagas.
Beta Was this translation helpful? Give feedback.
All reactions