Skip to content
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

Add Way to Exclude Calls from VerifyNoOtherCalls #1490

Open
rarcher opened this issue Jul 17, 2024 · 6 comments
Open

Add Way to Exclude Calls from VerifyNoOtherCalls #1490

rarcher opened this issue Jul 17, 2024 · 6 comments

Comments

@rarcher
Copy link

rarcher commented Jul 17, 2024

When verifying calls on mocks, it often happens that there is some trivial operation (like a property read) that you really don't care about, and the executing code is allowed to invoke any number of times. However, because of the way VerifyNoOtherCalls works, there's no way to mark things as ignored - you have to explicitly specify each individual call, which leads to unit tests either being too tightly coupled to the main code base, or using hackish work-arounds (like doing Times.AtMost(1000)). There ought to be a way to tell Moq that such-and-such a call just isn't relevant.

Back this issue
Back this issue

@rarcher
Copy link
Author

rarcher commented Jul 17, 2024

As side note, the most obvious way to implement this would be to let Times.AtLeast accept a 0 value as a parameter.

@kzu
Copy link
Member

kzu commented Aug 22, 2024

Wouldn't turn your mock into a loose mock and only verify what you're interested in work better in this case?

@rarcher
Copy link
Author

rarcher commented Aug 22, 2024

For situations where there aren't many methods you need to verify, sure. But the use case for this is when you have a LOT of functions, and you want to verify that most of them are never touched, with the possible exception of a few accessors. In that scenario, it's much more convenient to handle everything in bulk, using VerifyNoOtherCalls.

@kzu
Copy link
Member

kzu commented Aug 26, 2024

If most should not be called, then a strict mock with no setups for them seems like a better approach?

@rarcher
Copy link
Author

rarcher commented Aug 28, 2024

Hmmmm. Fair point. Maybe this is more of a documentation issue then? It is not obvious that strict mocks are the way to handle this case, for someone with limited familiarity with the library.

@kzu
Copy link
Member

kzu commented Sep 2, 2024

Yeah, perhaps. I guess this is something that is typically covered by the multiple blogs/stackoverflow/online curses you can find by now on using Moq itself. But I'll keep that in mind for vNext.

Feel free to close this issue if you feel the strict mock will suffice.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants