Assertion messages could be confusing

Here is the minimal example (body of some class Test):

public class Something { }

public interface IFoo
{
    void Method(Something x);
}
public interface Bar : IFoo { }

[Fact]
public void Test14()
{
    var fake = A.Fake<Bar>();
    fake.Method(new Something()); 
    // asserting different object
    A.CallTo(()=>fake.Method(new Something())).MustHaveHappened();
}

Prints:

FakeItEasy.ExpectationException : 

  Assertion failed for the following call:
    Test.Test+IFoo.Method(x: TestUtil.Attributes.Test+Something)
  Expected to find it once or more but didn't find it among the calls:
    1: Test.Test+Bar.Method(x: TestUtil.Attributes.Test+Something)

The method name/defining type should be the same in both cases not Test+IFoo.Method and Test+Bar.Method. Now it looks like there is other problem than the non-mathing parameter as it is the only different thing in the calls as printed.

Also <del>it would be helpful if the assert message would be different when no calls to a methods were made and when the parameter assertions does not match, because</del> it is kind of silly to print something like in the example where the actual parameter looks same as the required one.

[blairconrad]

I’m back with very little information, but in this message

Assertion failed for the following call:
  FIEQuestions.Test+IFoo.Method(x: Something 2)
Expected to find it once or more but didn't find it among the calls:
  1: FIEQuestions.Test+Bar.Method(x: Something 1)

The line that references “Something 2” makes up the reported type name using method.DeclaringType. The “Something 1” line makes up the reported type name using fakeManager.FakeObjectType.

That’s why we’re seeing the difference.

I’m half thinking that we might be better off with fakeManger.FakeObjectType all over.

[Bludator]

The printing via ToString() is something I didn’t think of and definitely should do 👍.