Anonymous
Anonymous

Reputation: 9648

How to test two objects are equal in xunit.net?

I am reading Test Driven Development: By Example. All examples use Java and Junit (I am on chapter 10). There are one test method that test for equality of two objects. I already override Equals of the class but when run my test it failed.

This is sample code

public class BaseX
{
    public string Test { get; set; }

    public override bool Equals(object obj)
    {
        return this.Test == ((BaseX)obj).Test;
    }

    public override string ToString()
    {
        return string.Format("Tyep: {0}, Test: {1}", this.GetType().Name, this.Test);
    }
}

public class A : BaseX
{

}

This is my test code

[Fact]
public void FunTest2()
{
    var b1 = new BaseX();
    var a1 = new A();

    b1.Test = "a";
    a1.Test = "a";

    Assert.Equal(a1, b1);
}

When I run the test, it will failed with this message.

TDD1.UnitTest.UnitTest1.FunTest2 : Assert.Equal() Failure
Expected: Tyep: A, Test: a
Actual:   Tyep: BaseX, Test: a

I think Assert.Equal compare both value and type of objects. So, I looked on xunit code and found that Assert.Equal call IEqualityComparer.Equals. If I want to compare two object with override method, what method should I use?

Update
I test this on Windows 7, Visual Studio 11 Beta, xunit.net 1.9.0.1566 (get files from nuget)

Upvotes: 8

Views: 22739

Answers (1)

seldary
seldary

Reputation: 6256

Before comparing both objects using T's Equals method, xunit compares types:

// Same type?
if (!skipTypeCheck && x.GetType() != y.GetType())
    return false;

As I see it, you have two choices:

The simple choice

Assert.True(b1.Equals(a1));

It might be less expected than an Equal overload, but KISS...

The less simple choice

public class BaseXComparer : IEqualityComparer<BaseX>
{
    public bool Equals(BaseX x, BaseX y)
    {
        return x.Test.Equals(y.Test);
    }

    public int GetHashCode(BaseX obj)
    {
        return obj.Test.GetHashCode();
    }
}

And then:

Assert.Equal(a1, b1, new BaseXComparer());

In this case, consider this.

Until someone will add a new overload (shouldn't be tricky, as the inner implementation has a bool parameter for this) or an extension, I'd recommend using the simple method above.

Upvotes: 7

Related Questions