Setup of method with an IEquatable argument gets lost with newest moq version

[Mys73rion]

When we update to the moq version 4.5.30 the test below fails.

If we remove the "Equals" attribute (it is from Fody) from the class "Bar" the test succeeds.
With the previous version we don't have this problem.

The setup from "bar1" gets lost somehow.

[Fact]
public void FactMethodName()
{
    var bar1 = new Bar();
    var bar2 = new Bar();
    var foo = new Mock<IFoo>();
    foo.Setup(x => x.Foo(bar1)).Returns("aa");
    foo.Setup(x => x.Foo(bar2)).Returns("bb");
    foo.Object.Foo(bar1).Should().Be("aa"); // fails 
    foo.Object.Foo(bar2).Should().Be("bb");
}

public interface IFoo
{
    string Foo(Bar bar);
}

[Equals]
public class Bar
{
    public override string ToString()
    {
        return "Bar";
    }
}

[MartinBuehlmann]

Same issue here. Any plans..?

[kzu]

Moq now supports mocking Equals, GetHashCode and ToString, which likely has an unexpected interaction with Fody. Dunno how it's implemented though, and what we should be doing.

Marking as up-for-grabs for now.

Thanks for reporting it!

[stakx]

As far as I understand it, Moq's current behaviour (which breaks the reported use case) is actually correct and should not be changed.

[Equals]
public class Bar
{
    public override string ToString()
    {
        return "Bar";
    }
}

This type definition and Fody's processing of it means that although Bar is a reference type, comparing any two instances for equality will yield true. For instance:

var bar1 = new Bar();
var bar2 = new Bar();

bar1.Equals(bar2) == true. Therefore, the following two setups are equivalent (since Moq matches these arguments using object.Equals) and the last one overrides the first one:

foo.Setup(x => x.Foo(bar1)).Returns("aa");
foo.Setup(x => x.Foo(bar2)).Returns("bb");

I don't think we can, nor should, change this behaviour. Doing so would probably break far more existing Moq setups and tests than it would fix.