Mocks with the same verifiable invocation setup multiple times
See original GitHub issueconst m = Mock.ofInstance(a => { });
m.setup(x => x(It.isValue(0))).returns(() => 0).verifiable();
m.setup(x => x(It.isValue(0))).returns(() => 0).verifiable();
m.object(0);
m.object(0);
m.verifyAll();
This fails with Verify Exception: Expected invocation on the mock 2 times, invoked 1 times
. Is this not a supported scenario? I have a test where I set up several invocations, and a couple of them end up with the same expected signature. Is it expected that I only register each one once, then verify that it was called the correct number of times?
Issue Analytics
- State:
- Created 7 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Moq - Is it possible to specify in a Setup the Verify criteria (e.g. ...
From what I can gather, Moq's Setup(SomeExpression).Verifiable() called along with Verify() , basically does a Verify(SomeExpression, Times.
Read more >Mockito Verify - DigitalOcean
Mockito verify() method can be used to test number of method invocations too. We can test exact number of times, at least once,...
Read more >A Unit Testing Practitioner's Guide to Everyday Mockito - Toptal
In this article, we'll cover multiple mock interfaces, listening invocations, matchers, and argument captors, and see firsthand how Mockito makes your tests ...
Read more >Mockito (Mockito 4.10.0 API) - javadoc.io
Verifying exact number of invocations / at least once / never ... is more important - when you stubbed the same method with...
Read more >Verifications - Unit Testing in C#
If your unit test uses multiple mocks, you can use Mock.Verify to verify all verifiable configuration at once.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hi, would you be able to verify if multiple registered setups work with
Mock.ofType<Interface>
when the matcher is exactly the same, please? From the docs and the above example I expected that it would.I have code that looks like this:
What happens is that the second setup trumps the first; so the first call receives
valueB
but the second call receivesundefined
. I found it interesting that all subsequent calls after the first returnundefined
and notvalueB
- though naturally both of those outcomes are undesirable as we wantcallA -> valueA
&callB -> valueB
. I would only expectedundefined
to be returned after the second call.If I remove the second setup then all calls to
funcThatReturnsPromise
returnsvalueA
as expected.Previously this test setup code differed in that the setups were both different because
funcThatReturnsPromise
was receiving an argument, so:This worked fine, so a call using
inputA
returnedvalueA
and so on.Any help would be much appreciated, thanks.
I guess it does make more sense to replay them in the order they were recorded. I’ve made the necessary changes.
Typemoq ver 0.1.1 is available and it includes these changes.
Please give it a try and let me know if you have any comments.