The result of setting up methods in an hierarchy of interfaces depends on the order by which they're set up

[dcastro]

Test Types:

public interface BaseA
{
    string Method();
}

public interface BaseB
{
    string Method();
}

public interface Derived : BaseA, BaseB
{
    new string Method();
}

Reproduce bug:

var mock = new Mock<Derived>();

mock.Setup(x => x.Method())
    .Returns("a");
mock.As<BaseA>().Setup(x => x.Method())
    .Returns("b");
mock.As<BaseB>().Setup(x => x.Method())
    .Returns("c");

var derived = mock.Object;
Assert.Equal("a", derived.Method());            //equals "c" <---- Test fails
Assert.Equal("b", (derived as BaseA).Method()); //equals "b"
Assert.Equal("c", (derived as BaseB).Method()); //equals "c"

If I change the order of the setups, so that Derived.Method is configured last, the program now prints "a", "b", "c" as expected and the tests pass.

var mock = new Mock<Derived>();

mock.As<BaseA>().Setup(x => x.Method())
    .Returns("b");
mock.As<BaseB>().Setup(x => x.Method())
    .Returns("c");
mock.Setup(x => x.Method())
    .Returns("a");

var derived = mock.Object;
Assert.Equal("a", derived.Method());            //equals "a"
Assert.Equal("b", (derived as BaseA).Method()); //equals "b"
Assert.Equal("c", (derived as BaseB).Method()); //equals "c"

[pjquirk]

I found this bug independently today working on an answer for this question on StackOverflow. Hopefully what I found can help.

[stakx]

Related: #22, which is also about shadowed members. It appears that it's not entirely clear what Moq does / should do in such cases.

[stakx]

@pjquirk, well spotted, this line of code, like you mentioned in your answer on Stack Overflow, indeed seems to be the reason for this peculiar behavior. Thanks for helping to identify the problem's cause!

I'll look into this some more tomorrow. My current guess is that it should be possible to first attempt to find a precise match, and only if there is none (or several equally good matches), fall back to the current .LastOrDefault behavior.

[stakx]

This should be fixed in the next release of Moq (version >4.7.63).

[pjquirk]

Thanks for the fix @stakx, and glad I could be of some use!