You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I've found in the past that when a mocked interface takes a large object it can make the verification of a call very large. This can mean the code isn't very readable and the failure message isn't able to distinguish exactly which field didn't match in the call vs. the verification.
Describe the solution you'd like
The best approach I've found is to split up the verification into a simple verification which just uniquely identifies a call and captures the complex object(s) and then subsequent assertions against the fields in those complex objects.
Describe alternatives you've considered
Can't really think of alternatives. The way I'm looking to solve it is already implemented in Moq.
Additional context
I've raised a PR that would allow the above (#780) this is my first NSubstitute PR and actually my first OSS PR so I'm more than happy to make changes if you folks feel there's a better way of doing it.
The text was updated successfully, but these errors were encountered:
I'd really like to progress with this issue and hopefully the fairly simple PR (linked to above) is sufficient - is anyone available to review/approve? It has occurred to me that instead of adding a new Arg.Do overload another way of tackling it would be to make the relevent ArgumentMatcher.Enqueue method public and consumer code can then call that rather than via Arg? @Romfos, @brad, @alexandrnikitin sorry to call you folks out but you're the last 3 committers and I'm hoping one of you may be able to find some time to review this PR?
Is your feature request related to a problem? Please describe.
I've found in the past that when a mocked interface takes a large object it can make the verification of a call very large. This can mean the code isn't very readable and the failure message isn't able to distinguish exactly which field didn't match in the call vs. the verification.
Describe the solution you'd like
The best approach I've found is to split up the verification into a simple verification which just uniquely identifies a call and captures the complex object(s) and then subsequent assertions against the fields in those complex objects.
Describe alternatives you've considered
Can't really think of alternatives. The way I'm looking to solve it is already implemented in Moq.
Additional context
I've raised a PR that would allow the above (#780) this is my first NSubstitute PR and actually my first OSS PR so I'm more than happy to make changes if you folks feel there's a better way of doing it.
The text was updated successfully, but these errors were encountered: