Using `verifyActionResult` and `testNextRender` sequentially results in confusion on external shared states
weverb2 opened this issue · comments
Discovered this while pairing with @steve-the-edwards:
Situation:
Using a Mock to verify a number of calls to a dependency of a Workflow
verifyActionResult
will apply the processedAction
to the current state and return a RenderTestResult
, but will not apply it to the next renders.
testNextRender
will also apply the processedAction
to the current state and return a RenderTester
allowing you to continue testing a flow of events in a workflow
The issue comes in when you are doing something like verifying calls against a mock. The action is technically applied twice to the same instance of state (potentially resulting in 2 calls to a mock when you expect 1) if you do a call chain like this:
.verifyActionResult { ... }
.testNextRender()
...
A solution could be a version of verifyActionResult
that also returns a RenderTester, so you could avoid the doubly applied actions.
cc @0legg who may have thoughts on this given he championed testNextRender
Got under my radar completely. Yep, it's a known issue, I've faced it before, but didn't find a way to easily fix it (like in one line). I would say "just make your actions idempotent" if I won't find a proper solution to it. :)
Actually, the issue is not only with testNextRender
, but with chaining a set of calls to verifyAction
or verifyActionResult
as well. One idea I have is to cache the result of the first call computing next state within RenderTestResult
. @steve-the-edwards , do you have any ideas about it?