SetupSequence and MockBehavior.Strict fails with "All invocations on the mock must have a corresponding setup."

[FindingNamo]

Hello friends,

I am trying to test a particular piece of code and want to make sure that every call to any stubs outside the method itself is done explicitly. For that, I've been relying on MockBehavior.Strict to ensure that any non-setup call would fail.

In this particular case though, the method makes 2 calls and, because it's implied that the first call changes state, the 2nd call is expected to return a different value. For that, I relied on SetupSequence.

However, it looks like the 2nd call doesn't seem to be perceived as being setup by the framework and thus fails with "All invocations on the mock must have a corresponding setup."

Snippet:

var someMock = new Mock(MockBehavior.Strict);

someMock .SetupSequence(m => m.DoSomething(It.IsAny(), It.IsAny())).ReturnsAsync(firstDesiredResult).ReturnsAsync(secondDesiredResult);

var classUnderTest = new ClassUnderTest(someMock);
classUnderTest.DoWork(); // This is where DoSomething is called twice

We end up with with a failure where telling us "All invocations on the mock must have a corresponding setup."

Running it in Loose mode runs fine.

Am I running into a bug since I did setup the sequence or am I misunderstanding?

Cheers!

[stakx]

Hard to say something since you omitted the part of your repro call that actually does the invocation. Also, the error you're citing doesn't just appear out of nowhere, you've also omitted the verify call from the above code.

Please provide minimally complete repro code that'll allow us to reproduce the error you've observed. Otherwise there's nothing we can do about it.

[FindingNamo]

Ah ha! Thanks for rubber ducking it with me. Spent way too much time on this before getting your reply and everything cleared up. It ended up being an NCrunch issue where it somehow didn't pick up the changes made to return a 2nd value and thus was failing for the 2nd call despite the 2nd ReturnAsync which of course would lead it failing the way it does.

Not that it matters now anymore but it was failing at invocation time (where classUnderTest.DoWork(); happens) before the actual verification on the mock itself.

Thanks again!