Verify can create setups that causes a subsequent VerifyAll to fail

[stakx]

Reproduction code:

public interface IX
{
    IX X { get; }
}

var mock = new Mock<IX>();
mock.Verify(m => m.X.X, Times.Never);
mock.VerifyAll();

Actual behavior:

VerifyAll throws a MockException with message:

The following setups on mock 'Mock<IX:00000001>' were not matched:
IX mock => mock.X

Expected behavior:

All verification steps should pass because there are no invocations nor any setups.

[lepijohnny]

There are more cases affected by this one as well. I would like to share them as they are, IMO, all related with the way how FluentMockVisitor unfold fluent expression into inner mocks with setup even though Verify has been called, not Setup actually. It seems that Verify using fluent expression add (unexpected) side effects.

1. MochBehaviour.Strict has been avoided

Reproduction code:

public interface IX
{
    IX X { get; }
}

var mock = new Mock<IX>(MockBehavior.Strict);
mock.Verify(m => m.X.X, Times.Never);
var _ = mock.Object.X;

Actual behaviour

No exception

Expected behavior

MockException has been thrown as there is no setup for m.X

2. It is possible to invoke method\property without proper setup

Reproduction code:

public interface IX
{
    IX X { get; }
}

var mock = new Mock<IX>();
mock.Verify(m => m.X.X, Times.Never);
var _ = mock.Object.X.X;

Actual behaviour

No exception

Expected behavior

NullReferenceException has been thrown because we didn't setup return value for IX and it should be null.

3. Override the existing setup(IMO the most dangerous)

Reproduction code:

public interface IX
{
    IX X { get; }
   int Count { get; }
}

var mock = new Mock<IX>();
var nested = new Mock<IX>();
nested.Setup(m => m.Count).Returns(5);
mock.Setup(m => m.X).Returns(nested.Object);

mock.Verify(m => m.X.X, Times.Never);
int c = mock.Object.X.Count;

Actual behaviour

c is 0

Expected behavior

c is 5 as there is only one setup for it.

[lepijohnny]

@stakx - FluentMockVisitor translate the fluent expression the same way, it doesn't matter if it is Setup or Verify. It will always, if inner mock is not there, create one, SetupAllProperties and add the Setup. This could lead to pollution of the mock and this vague behavior. What would be drawback of introducing additional info and passing it to FluentMockVisitor in order to avoid setup at all if verify is invoked?

[stakx]

@lepijohnny - I am already busy re-architecting the way how recursive / "multi-dot" setup and verification expressions are processed internally. Once I'm done with that, FluentMockVisitor will likely no longer be needed at all. ;-)

(I should probably mark this and some other issues as "assigned to myself" so others know that a bugfix is already being prepared.)

[lepijohnny]

Sure, makes sense 👍

[stakx]

@lepijohnny - Those bugs are gone now. I mentioned you in the changelog entry because you kindly provided a lot more test cases than I originally thought of; they've made it into the code base (here). Thanks for contributing those! 👍

[lepijohnny]

@stakx - I appreciate that! Great job btw! 👍