How exactly are arguments matched?

[Skeve]

Hi,

I am new to this framework and mocking so take this as a beginner's
question.

I am expecting to receive a call on a "fakeMessageStore" with a
"built_message" object, but I am changing the state of the
"built_message" prior to checking that the call is received - yet the
test still passes. How is equality determined for the actual and
expected parameters. (I have overrridden public override bool
Equals(object obj) for CommMessage class.)

Here is an extract of the code, which hopefully makes things clearer.

Code under test:

// in Gateway class
public void PostLocation(GPSdataPacket gps_location)
{
CommMessage message =
message_builder.BuildMessage(gps_location);
message_store.Add(message);
}


Test code (which passes):

var fakeMessageBuilder =
Substitute.For<IMessageBuilder>();
var fakeMessageStore = Substitute.For<IMessageStore>();
//construct built_message with MessageId = 1

fakeMessageBuilder.BuildMessage(gps).Returns(built_message);

// construct gateway with fakes, create test gps co-
ordinate
gateway.PostLocation(gps);

fakeMessageBuilder.Received().BuildMessage(gps);
// change state of build_message
built_message.MessageId = "2";
fakeMessageStore.Received().Add(built_message);

[David Tchepak]

Argument equality is currently checked using EqualityComparer<object>. (The code for it is here: http://bit.ly/fQ7ncu)

Can't for the life of me remember why we've done it this way (rather than use Object.Equals; I think it's a remnant of when this arg spec class was generic), but it basically means you get reference equality. :)

If this is causing you problems let me know; it is probably reasonable to use Equals() as defined on the specific argument type, although for reference types it could also be misleading if the right reference came through but the state was altered after the fact (say, by the call under test itself). Based on the method being tested in this example, I guess I'd expect "fakeMessageStore.Received().Add(built_message);" to pass regardless of built_message state changes (YMMV :)).

I realise this example is just a snapshot so there's lots of context I'm missing, but in general I'd recommend creating a new message for a new MessageId rather than mutating state, which neatly side-steps the whole issue. :)

Hope this helps a little. Please let me know if I'm missing anything obvious.

Regards,

David

--
You received this message because you are subscribed to the Google Groups "NSubstitute" group.
To post to this group, send email to nsubs...@googlegroups.com.
To unsubscribe from this group, send email to nsubstitute...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nsubstitute?hl=en.

[Guido Tapia]

HI David,

I think I've just been bitten by this, is this still the case in the latest NSubstitute?

I'm comparing two arrays, I know that the elements in the array are equal (not reference) but the arrays are not the same reference.

Thanks

[Guido Tapia]

Apologies, creating a wrapper for the array (implementing Equals) did the trick.

It would be nice however if the mock could do something like:

mock.Received().Method(Arg.Equivalent(arr));

Not sure of the syntax.  Anyways, no big deal, it was user error.

[David Tchepak]

Hi Guido,

You can use Arg.Is(x => your_logic_here(x)) to pass through some custom comparison logic.

There is also work well under way to support custom matchers to make it easier for people to reuse these bits of logic.

Regards,

David

--

You received this message because you are subscribed to the Google Groups "NSubstitute" group.

To view this discussion on the web visit https://groups.google.com/d/msg/nsubstitute/-/gP7NfU4bleMJ.

[Guido Tapia]

Sweet, just what I was after.

Thanks