Using verifyActionResult and testNextRender sequentially results in confusion on external shared states

[weverb2]

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.

[steve-the-edwards]

cc @0legg who may have thoughts on this given he championed testNextRender

[0legg]

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. :)

[0legg]

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?