-
-
Notifications
You must be signed in to change notification settings - Fork 802
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VerifyNoOtherCalls verifies other mocks after upgrade from 4.10.1 to 4.11.0 #858
Comments
Yes.(*) That setup establishes a kind of "ownership" relationship between In Moq, verification via I would guess that you could change your verification to either: repositoryMock.VerifyGet(r => r.UnitOfWork, Times.Once);
+unitOfWorkMock.Verify(r => r.SaveEntitiesAsync(It.IsAny<CancellationToken>()), Times.Once);
repositoryMock.VerifyNoOtherCalls();
-unitOfWorkMock.Verify(r => r.SaveEntitiesAsync(It.IsAny<CancellationToken>()), Times.Once);
-unitOfWorkMock.VerifyNoOtherCalls(); or, to better express the "ownership" of repositoryMock.VerifyGet(r => r.UnitOfWork, Times.Once);
-repositoryMock.VerifyNoOtherCalls();
-unitOfWorkMock.Verify(r => r.SaveEntitiesAsync(It.IsAny<CancellationToken>()), Times.Once);
+repositoryMock.Verify(r => r.UnitOfWork.SaveEntitiesAsync(It.IsAny<CancellationToken>()), Times.Once);
-unitOfWorkMock.VerifyNoOtherCalls();
+repositoryMock.VerifyNoOtherCalls(); (*) Note however that this is more for consistency with the recursive behavior of the preexisting (**) If you don't like the fact that Moq automatically includes the +repositoryMock.Setup(m => m.UnitOfWork).Returns(() => unitOfWorkMock.Object);
-repositoryMock.Setup(m => m.UnitOfWork).Returns(unitOfWorkMock.Object); |
@molszews, has your question been sufficiently answered? |
makes perfect sense, thanks! |
Calling `VerifyNoOtherCalls` isn't needed anymore. There's no need to verify the connection. This change was necessary to make the tests pass again. See issue devlooped/moq#858.
I just ran in the same case and I feel like this change should'nt have been made. Consider the following :
And this test
I dont care about what SubjectToTest does with the entity. I care about it retriving the good entity and returning the good result. The call to entity's properties made by the method seems like implementation details to me, wich I don't have to worry about when testing. Maybe it's usefull for other test cases. Many test strategies can be used. In this case I used mock for the IEntity simply to avoid creating a class that implements the interface as it is not needed. The workaround of using the override of If the behavior is still wanted, it could be nice to mark a mock as « non verifiable » when creating it, e.g. |
Code change needed due to devlooped/moq#858
This is a very unfortunate design decision. I only discovered this behavior today even though I used Moq for years. This alone tells you how obscure this feature is. This behavior is not documented anywhere besides this old ticket. The main problem with this is it can make tests rot. Imagine someone wrote a test which used this feature, either because they knew about it, or most likely by accident: // ...
aMock.Setup(x => x.Foo()).Returns(bMock.Object);
bMock.Setup(x => x.Bar()).Returns(1);
// ...
aMock.VerifyNoOtherCalls(); This implicitly verified that Now imagine I need to make a change to this test, and for some reason I need a lambda in the first setup: aMock.Setup(x => x.Foo()).Returns(() => {
// do stuff
return bMock.Object;
}); The test still passes, but unbeknownst to me, I lost verification on A related issue is that the test behavior depends on an obscure implementation detail of the Moq framework, namely whether it was "smart" enough to discover the dependency. This ticket mentions that currently a workaround is to wrap the return into a lambda. But what if at some point, some maintainer decides to make it smarter and detect lambda returns? Will my tests break? Finally, tests are a form of documentation, and documentation needs to be clear. Reliance on implicit behavior which only works sometimes diminishes documentation value. |
having following piece of code
it will break after doing Moq update with following exception:
i.e. in a line
repositoryMock.VerifyNoOtherCalls();
which means it will now for some reason verifies all mocks at once. I assume it is due to the relation between these two, i.e.repositoryMock.Setup(x => x.UnitOfWork).Returns(unitOfWorkMock.Object);
is that the intended behaviour?
The text was updated successfully, but these errors were encountered: