Add assertion similar to Moq's `VerifyNoOtherCalls` about fakeiteasy HOT 8 CLOSED

Sorry about being unclear.

I had thought it would verify that no calls were made other than the ones configured, not asserted.

That's the thing though, it should verify that no other calls were made except for the expected (i.e. the already asserted) calls.
That would simplify the setup quite a lot, because this does not need strict configuration and we could often simply use the fresh, loose fake directly for verification.

I unfortunately can't access a machine at the moment, but will try to whip up something on Monday!

from fakeiteasy.

Hi, @ChristoWolf. Thanks for your interest in FakeItEasy.

I'm having problems finding Moq's documentation for VerifyNoOtherCalls. Is the description in

from fakeiteasy.

Using Moq: A Simple Guide to Mocking for .NET accurate?

I think your fear is that you'd configure a strict Fake, use it in your system under test, and a bonus method would be called and the system under test would eat the exception raised by the Fake and nobody would know that something unexpected happened?

Without changing FakeItEasy's code, today you could get the calls that were received and examine them, seeing if any of them were outside the ones you allow-listed. Then again with a complex strict Fake, I can see how this would get onerous. And brittle.

This seems like a useful feature. What think you, @thomaslevesque?

I have an idea how to implement this, but the stuff for that is not accessible from consumer code.

Oh, I'd be keen to hear what you thought.

One implementation that I thought of, that might not be too disruptive, would be to add a member to FakeItEasy.Core.StrictFakeRule, capturing the unanticipated calls that are received. Then one could check the Fake to see if the list were empty.

Oh! This is implementable in user code. At least for a proof of concept. Make a copy of StrictFakeRule. Add the list of received calls that I just mentioned. Then manually apply that rule to your Fake. And you'll have the rule sitting right there and you can interrogate it.

from fakeiteasy.

My first thought when I started reading the issue was "just use a strict fake", but it's true that the ExpectationException could be catched in the SUT and never seen from the tests...

for use cases where strict fakes would need complex setups.

Do you mean that you can't use a strict fake because there would be too many calls to configure, so you want to rely on the default fake behavior? But in this case, all those unconfigured calls would be caught by VerifyNoOtherCalls, wouldn't they? So basically you have to configure them, if you want to make sure no unexpected call happens.

from fakeiteasy.

Hi guys!

Yes, that method's description is accurate.
In other words, the mock not only tracks the calls on it, but also for which methods Verify has been called.
These lists are then compared.

To better explain my use case:
Sometimes, an interface might be quite large (which I am of course not a big fan of), and setting up its methods for strict faking would be quite cumbersome.
Moreover, when I would then verify that certain calls have been made (especially using ordered assertions), I would again have to assert on the same methods again.

from fakeiteasy.

I think I'm more confused now.
I had thought it would verify that no calls were made other than the ones configured, not asserted.

Is this supposed to be used when the Fake isn't strict? As a way to avoid an overly complicated strict Fake configuration?

Maybe show us a sample usage?

from fakeiteasy.

Sorry about being unclear.

Oh, don't be sorry. Maybe it's me. It often is.

from fakeiteasy.

There's been no activity in this issue for some time, so we're closing it.
We can reopen the issue in the future should sufficient interest arise.

from fakeiteasy.