-
-
Notifications
You must be signed in to change notification settings - Fork 812
Add Times Expectation to the mock setup #1210
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
Comments
or mock
.Setup(foo => foo.Add("my string"), Times.Once)
.Returns(true) |
I'll have to look up the issue where we discussed this topic last, but IIRC we ended up with |
Implementation is up to you |
@stakx I am currently trying to migrate away from RhinoMocks and our codebase is heavily relying on the repeat functionality offered on setups. I have read through the past discussions here and here and all topics stayed unresolved due to alternatives. I wanted to share my bits on what we would actually need and maybe there is still a chance to get some solution to our issue:
We are verifying our overall Mocks with
With RhinoMocks we typically got an exception within the application code as soon as some repetition was violated and we would love to get the same behavior with our future framework. This software has more than 8yrs of history already and the test suite has grown over time. Migrating our whole test suites to a separate approach is not feasable, there is a high risk we loose our coveragte by introducing bugs into the tests. For migrational purposes it would be beneficial if such repeat configurations are possible through extension methods on the |
Moq can do some of that via the
mock.Setup(...).AtMostOnce();
Moq setups will not throw at invocation time if you haven't set up either a However, Also, #937 may or may not be relevant in your case.
mock.Setup(...).AtMost(2);
mock.Setup(...).Throws(...);
mock.Setup(...).AtMost(0);
This is the one where Moq is currently lacking something. As you've seen for the above examples, Moq can already deal with "at most N times" even before verification; but it does not offer a means to specify "at least N times" before verification. |
Have you considering unmarking the |
I am a bit reluctant to migrate our codebase to a mechanism which is marked obsolete. Removing the obsolete flagging would be step one, but it is also a strategic thing whether Moq plans to really support this functionality in future. If maybe in 1-2yrs a Moq5 comes out, it sounds like quite a risk that it still might be removed. |
@Danielku15, it is my understanding that Moq 5's main API is really quite different from Moq 4's (it's a new major version for good reason!). It does have a special back-compat API to make the transition from 4 to 5 easier, but if you really want to update at some point, you'll likely have to adjust/rewrite some tests anyway. That being said, I fully understand that basing code on ostensibly obsolete features doesn't feel nice. De-obsoleting |
@stakx Of course an upgrade between major versions also imply a certain level of breaking changes. But I would say for most libraries it rarely means large conceptional changes which have implications that you have to reorganize your code in a large scale. Unfortunately this topic is one of these rare cases. Conceptionally it is a different mentality to change the repetition aspect from the arrange phase to the assert phase of a test. And this in a result leads to large scale refactorings implying quite a risk that everything is really as before.
In our case the I was already able to migrate the our first product to Moq and 2686 of 2721 tests are already green. There are some small sacrifices but we can live with them until we rework these tests. Like: I temporarily made an own extension method and silenced the deprecation warning with a Just sharing some insights in the hope that future readers can learn from how I solved my issues 😉 So it would be great if we can de-obsolete AtMost[Once] for Moq4. You'd have my vote for it. |
@asmejkal and @Danielku15, it's been some time and you have probably moved on in the meantime, but in case you're still interested: while I'm probably not going to de-deprecate |
Add
Times
expectation to the mock setup, and we can verify setup using single linemock.VerifyAll()
ormockRepo.VerifyAll()
The text was updated successfully, but these errors were encountered: