Question

I am stubbing two different objects. Here are the interfaces:

public IInterface1
{
    IEnumerable<Foo> Method1(int p1, string p2 = null, string p3 = null);
}

public IInterface2
{
    Bar Method2(int p3, int? p4 = null);
}

As you can see, both have parameters that default to null. However, one is matching my Expect, and the other isn’t. This stub works; when its method is called with a value matching testData.p1, it returns an array of two Foos:

var obj1 = MockRepository.GenerateStub<IInterface1>();
obj1.Expect(m => m.Method1(
         Arg.Is(testData.p1), 
         Arg<string>.Is.Null, 
         Arg<string>.Is.Null))
    .Return(new[] { new Foo(), new Foo() });

However, this similar stub is not returning the expected result, returning null instead, despite the parameters matching the expectation:

var obj2 = MockRepository.GenerateStub<IInterface2>();
obj2.Expect(m => m.Method2(Arg.Is(testData.p3), Arg<int?>.Is.Null))
    .Return(new Bar());

Why is this second stub not matching on my parameters? Even if I use Arg<int?>.Is.Anything for the second expected parameter, null is still returned.

Update

OK, I found an alternate way to set up my expectation, passing the expected values instead of using Arg:

obj1.Expect(m => m.Method1(testData.p1, null, null))
    .Return(new[] { new Foo(), new Foo() });

obj2.Expect(m => m.Method2(testData.p3, null))
    .Return(new Bar());

Both stubs return the expected results when I set them up this way. I’m still unclear on the distinction and why one worked with Arg and the other didn’t. I suppose this is yet another time where I’m getting confused about the mixing of AAA, record/replay, mocks, and stubs in this library. Can anyone dispel my confusion about why the original code didn’t work?

Answer 1

At runtime, when you pass a null to the second parameter of IInterface2, .NET will create a Nullable<int> and pass that to your method implementation. Your implementation code can then check p4.HasValue and do whatever you want to account for null values.

But from Rhino.Mocks standpoint, when it intercepts the method call, it’s going to see that the second parameter is a Nullable<int> (not a null instance) and therefore you won’t match on your expectation.

In the second attempt, when you pass null directly, the runtime will, again, wrap that null up in a Nullable<T>. Rhino.Mocks will check the two parameters for equality (to see if you have a matching expectation). Nullable<T> overrides the Equals method to check if both of the Nullable<T>‘s have null and will return true — thus matching your expectation.