-
-
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
Expose Moq.Times' Verify and Kind #970
Comments
Why not deconstruct a |
The deconstruction is what we're going to have to do for now, but that means we're duplicating the code already in |
I understand how exposing It would be safer to instead expose some Those would however be somewhat strange (highly specific) things to add to Moq's API that most people will probably never use. |
I checked with Moq 5's So here's another idea @dmcbride: What if we added a
That is, the string representation would be very much akin to the code used to build the instance, allowing you to search for the static factory method names to figure out what kind a It certainly isn't the most ideal solution for your exact problem, but should work well for the general case. I'm also fine with exposing the |
The resultant message would be less than perfect English, but since it's not going to users, only developers, I think that would work very well. We'd end up with code that calls Validate, and if that returns false, throws an exception with a message like |
Consider it done @dmcbride .
An unparameterized (You could of course parse the returned string into whatever English representation you like — as long as we don't change the formatting of |
We would like to write some additional moq-like tests specific to our environment where we are counting items that must fit in a range the same way that
Times
already does. Now, we could basically reproduce theMoq.Times
struct in our own code, but that seems awfully wasteful when all we would need from Moq is to expose theVerify
method and theKind
of the object, and we could easily reuse the struct for any other counting purpose.We have to reproduce the
GetExceptionMessage
method as the message itself would be dramatically different for our use case, but there's nothing that can be done about that. However, we cannot reproduce it without access toKind
as we wouldn't know which message to use to give the developer the most useful exception message.The text was updated successfully, but these errors were encountered: