What is the purpose of Verifiable(Func<Times> times) if not deferral?

[Ghostbird]

I expected this to work:

var pushCount = 0;
var stackMock = new Mock<Stack<string>>();
stackMock.Setup(s => s.Push(It.IsAny<string>())).Callback(() => pushCount += 1);
stackMock.Setup(s => s.Pop()).Verifiable(() => Times.Exactly(pushCount));
var sut = new MyClass(stackMock.Object);
var act = MyClass.MethodThatShouldNotLeakStackOnError;
await act.Should().ThrowAsync<InvalidOperationException>();
mock.VerifyAll();

However, when I debug this, the lamba in …s.Pop()).Verifiable( is called immediately at Setup time. I expected it to be deferred to the time of verification because:

• I can think of a use-case for that
• I can concisely write a verification that I otherwise can't.

What then is the purpose of that overload, if not deferral? It seems its current use means that I might just as well run the code in the lambda on the line before the setup.

[GillesTourreau]

The Verifiable(Func<Times> times) allows to use some Times methods, like Times.Once() or Times.AtLeastOnce() without using ().

For example you can use Verify(Times.Once()) or Verify(Times.Once), it is exactly the same behavior.
It is just a syntax sugar to make the Verify() method more natural to read...

[Ghostbird]

Ah, that makes perfect sense. In fact I had been using Verifiable(Times.Once) and briefly was surprised by the seeming difference between Verifiable(Times.Once) and Verifiable(Times.Exactly(2)). I didn't dwell on it, and failed to connect it to this signature.

I guess in my use case above, I'd better construct the test in such a way that I use Verifiable(Times.Exactly(x)) for both the Push and Pop and build it in such a way that the x is known in advance.

Another option, if it is hard to know the value of x in advance, is to make Push increment a counter, and Pop decrement that counter, and assert its value at the end.

[GillesTourreau]

Another option, if it is hard to know the value of x in advance, is to make Push increment a counter, and Pop decrement that counter, and assert its value at the end.

Yes, you use the right approach with the Callback() method to count the number of calls if you don't know it exactly.

If you want to check the number of calls, you can call explicitely the Verify() at the end of your unit test (for me it is more better design if you want to respect the Arrange/Act/Assert patter):

stackMock.Verify(m => m.Pop(), Times.Exactly(pushCount));