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?