NSubstitute icon indicating copy to clipboard operation
NSubstitute copied to clipboard

Received test with argument matcher needs more failure information

Open manzanotti opened this issue 10 years ago • 4 comments

I don't know if I'm just missing how you do this, but I'm testing that my method is calling a substituted class with a parameter that has a property with a specific value, i.e. using an argument matcher:

SubstitutedService.Received(1).CalledMethod(Arg.Is<Entity>(e => !e.Children.Any()));

When this test fails, the error message returned is along the lines of:

Actually received no matching calls.
Received 1 non-matching call (non-matching arguments indicated with '*' characters):
CalledMethod(*Entity*)

i.e. it doesn't actually give me any information about what the actual value of the property is versus the expected value. This obviously makes it a lot harder to work out why a test is failing.

Is there a way to do this that I've just missed from the documentation, or is this an oversight in NSubstitute?

manzanotti avatar Nov 21 '14 14:11 manzanotti

Hi Paul,

It's not implemented. There is some plumbing there to allow custom matchers with decent messages (example). I think we could get it working for your example by making ExpressionArgumentMatcher implement IDescribeNonMatchers so it will work with ArgSpecification.DescribeNonMatch.

Regards, David

dtchepak avatar Nov 21 '14 22:11 dtchepak

I'm surprised this hasn't been a hotter issue! One of the first features I looked for when looking for alternatives to Rhino Mocks was an equivalent to "GetArgumentsForCallsMadeOn". However, as @dtchepak pointed out to me in this discussion, a better solution is just to provide a better, more detailed message when you have more complicated argument matching. Personally I think this would be a significant improvement over Rhino Mocks and would be an attractive way of differentiating NSubstitute.

I forked the repo and was going to try to make the change myself but it looks like a bit of a dangerous first contribution for me so I should probably go after something more simple.

I.e. I would love to see this issue get addressed and I would I could do it myself :)

jakejgordon avatar Dec 06 '16 02:12 jakejgordon

Yes I don't think this is an easy first change. :) See also #160.

dtchepak avatar Dec 06 '16 05:12 dtchepak

Although this issue is a little dusty, is there any way to get more failure information when just using Received instead of any Arg.Do stuff?

I really like the readability of assertions with Received, but would appreciate more detailed failure information.

suchja avatar Aug 09 '23 17:08 suchja