Make verifyAction and verifyActionResult support no processed action.

[zach-klippenstein]

Closes #885.

cc @ijwhelan

[zach-klippenstein]

Is this too lenient? Should this method require no action to have been processed at all? The current behavior could let through an action that has complex logic that just happens to set the state to it's previous value.

[rjrjr]

My knee-jerk is that a literal "no action was fired" assertion is too much of an implementation detail to encourage in testing. But the real question is whether this satisfies the original requester.

[zach-klippenstein]

An alternative is to allow verifyActionResult to handle the case where no action was fired and just treat it like a no-op action, but that raises the same concern about actions that "just happen" to be no-op.

[ijwhelan]

So the original use case I had in mind for this was verifying the following behavior:

• User has entered invalid data into a simple form
• User presses the submit button
• Ensure that no network request was made to actually submit the data

The motivation for this test was to ensure that I'm being properly defensive against the UI not respecting the data validity flag in the state and leaving the submit button enabled. I want to make sure that the lambda I'm handing to the UI to fire when the submit button is clicked is actually a no-op.

I agree that actions are implementation details and I don't want to expose them outside of the workflow, but I think allowing no-op actions might open up some gaps in a test like the one I'm trying to write.

[zach-klippenstein]

Reworked this PR: no more verifyNoAction, instead verifyAction and verifyActionResult let you assert noAction.

[rjrjr]

Still LG.

[dhavalshreyas]

Sweet!