We are trying to implement saga-tests with redux-saga-test-plan & would like to initialize the client and use its store and DocumentService in the tests instead of mocking it. The sagas we want to test use the DocumentService to manipulate GroupInstances. My questions would be if this a reasonable/doable approach and if there’s documentation or examples for starting the client and using it in saga-tests.
We don’t have experience specifically with implementing saga-tests using redux-saga-test-plan. However, for testing sagas, the client documentation suggests that the preferred method is to run the entire saga and verify that the expected effects occur. For internal Client sagas, it recommends using a stubbing library like Sinon. You can find more detailed information in the client documentation.
Hey @christian-firm-anchor,
was the answer provided sufficient or are there question left on you side?
As usual, the answer is: It depends. 
First of all, if you want to test sagas, i.e. the actual generator functions, then there’s no other way than to use redux-saga-test-plan, as far as I know.
However, depending on the complexity of the saga itself, it can become quite complex to setup the test fixtures.
The reason is that a saga can call a lot of additional generator functions which can be complicated to mock using provide(). If you don’t want to or cannot use provide(), you might have to pass a proper store for those generator functions to work properly as well. This too can be tedious to setup.
Furthermore, many of the A12 client API selectors unfortunately cannot be used in provide() because their signatures don’t work with provide.
The selectors must be defined as a function that expects the state and possibly more parameters.
However, the client API selectors are functions that expect a parameter and then return a function that expects the state, i.e. they are rather selector providers than selectors in the redux sense.
Ultimately, I think if you can extract the most complex part of your functionality into a non-generator function and test this using a standard unit test, you will probably be better off.
If it must be generator function then it’s beneficial if it has very few dependencies to other generator functions because of above mentioned points.
If the saga itself is not too complex, redux-saga-test-plan is a good tool to use.