Home/ Questions/Q 7511927
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T23:42:41+00:00

I was trying to perform subsequent calls verification and I found that moq supports

  • 0

I was trying to perform subsequent calls verification and I found that moq supports the InSequence() method for this, like:

MockSequence s = new MockSequence();
validator.InSequence(s).Setup(m => m.IsValid(It.IsAny<Frame>())).Returns(true);
encryptor.InSequence(s).Setup(m=>m.Encrypt(It.IsAny<Frame>()));
socket.InSequence(s).Setup(m => m.Send(It.IsAny<Frame>()));
compressor.InSequence(s).Setup(m => m.Compress(It.IsAny<Frame>()));

However, this seems to be working only when I specify mock behavior as “strict”, which forbids me calling additional mehods on mocked objects. I’d like, however, to be able to call other methods on those objects, I just want THESE calls to be performed in sequence.

Is there any “supported” way for that (instead of resorting to .Callback() and handmade implementation)? I found an additional library called moq.sequence, however, the precompiled version doesn’t work with latest Moq.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Ok, I investigated the case myself by digging into Moq’s source code in the SVN Browser (just for the record – the moq version in question is Moq.4.0.10827.Final).

    My investigation led me to:
    http://code.google.com/p/moq/source/browse/trunk/Source/MockSequence.cs?spec=svn751&r=712

    By looking at the InSequence() method, I can see now that the whole implementation is based on the When() method.

    So, in reality, the following code:

    validator.InSequence(s).Setup(m => m.IsValid(It.IsAny<Frame>())).Returns(true);

    ends up as something like:

    validator.When(/* call is made in sequence */).Setup(m => m.IsValid(It.IsAny<Frame>())).Returns(true);

    In other words, this is just setting up a conditional behavior – when the method is invoked in sequence, the specified Setup() comes into play. Otherwise, default implementation is executed. And because for a strict mock, the default implementation is to throw exception (the call is treated as unspecified), the whole solution works.

    Hence, it seems getting current solution to work with loose mocks would be quite cumbersome. I’ll just stick to homemade solutions based on Callback() (which can be really nicely wrapped, by the way) – it takes away the ability to use callback for other means, however, I wasn’t using it anyway.

    I am posting this answer in hope it is useful.

    • 0