C# - Asserting two objects are equal in unit tests

Question

Either using Nunit or Microsoft.VisualStudio.TestTools.UnitTesting. Right now my assertion fails.

    [TestMethod]
    public void GivenEmptyBoardExpectEmptyBoard()
    {
        var test = new Board();

        var input = new Board()
            {
                Rows = new List<Row>()
                    {
                        new Row(){Cells = new List<int>(){0,0,0,0}},
                        new Row(){Cells = new List<int>(){0,0,0,0}},
                        new Row(){Cells = new List<int>(){0,0,0,0}},
                        new Row(){Cells = new List<int>(){0,0,0,0}},
                    }
            };

        var expected = new Board()
        {
            Rows = new List<Row>()
                    {
                        new Row(){Cells = new List<int>(){0,0,0,0}},
                        new Row(){Cells = new List<int>(){0,0,0,0}},
                        new Row(){Cells = new List<int>(){0,0,0,0}},
                        new Row(){Cells = new List<int>(){0,0,0,0}},
                    }
        };

        var lifeOrchestration = new LifeOrchestration();

        var actual = lifeOrchestration.Evolve(input);

        Assert.AreEqual(expected, actual);
    }

Answer 1

You've got two different Board instances, so your call to Assert.AreEqual will fail. Even if their entire contents appear to be the same, you're comparing references, not the underlying values.

You have to specify what makes two Board instances equal.

You can do it in your test:

Assert.AreEqual(expected.Rows.Count, actual.Rows.Count);
Assert.AreEqual(expected.Rows[0].Cells[0], actual.Rows[0].Cells[0]);

// Lots more tests of equality...

Or you can do it in your classes: (note I wrote this on-the-fly - you'll want to adjust this)

public class Board
{
    public List<Row> Rows = new List<Row>();

    public override bool Equals(object obj)
    {
        var board = obj as Board;

        if (board == null)
            return false;

        if (board.Rows.Count != Rows.Count)
            return false;

        return !board.Rows.Where((t, i) => !t.Equals(Rows[i])).Any();
    }

    public override int GetHashCode()
    {
        // determine what's appropriate to return here - a unique board id may be appropriate if available
    }
}

public class Row
{
    public List<int> Cells = new List<int>(); 

    public override bool Equals(object obj)
    {
        var row = obj as Row;

        if (row == null)
            return false;

        if (row.Cells.Count != Cells.Count)
            return false;

        if (row.Cells.Except(Cells).Any())
            return false;

        return true;
    }

    public override int GetHashCode()
    {
        // determine what's appropriate to return here - a unique row id may be appropriate if available
    }
}

Answer 2

I used to override getHasCode and equals, but I never liked it since I don't want to change my production code for the sake of unit testing. Also it's kind of pain.

Then I turned too reflection to compare objects which was less invasive...but that's kind of lot of work (lots of corner cases)

In the end I use:

http://www.nuget.org/packages/DeepEqual/ Works great.

Update, 6 years later:

I now use the more general library fluentassertions for .NET it does the same as above but with more features and a nice DSL, the specific replacement would be: https://fluentassertions.com/objectgraphs/

PM> Install-Package FluentAssertions

Also after some years of experience, I still not recommend the override route, I'd even consider it a bad practice. If you're not careful you could introduce performance issues when using some Collections like Dictionaries. Also when the time would come where you will have a real business case to overload these methods you'd be in trouble because you'd have this test code in there already. Production code and test code should be kept separated, test code should not rely on implementation details or hacks to achieve their goal, this make them hard to maintain and understand.

Answer 3

For trivial objects, like domain objects or DTOs or entities, you could simply serialize both instances to a string and compare that string:

var object1Json = JsonConvert.SerializeObject(object1);
var object2Json = JsonConvert.SerializeObject(object2);

Assert.AreEqual(object1Json, object2Json);

This of course has various caveats, so evaluate whether for your classes, the JSON contains the expected values that should be compared.

For example, if your class contains unmanaged resources or otherwise not serializable properties, those won't be properly compared. It also only serializes public properties by default.

Answer 4

ExpectedObjects would help you to compare equality by property value. It supports:

1. simple object: expected.ToExpectedObject().ShouldEqual(actual);
2. collection: expected.ToExpectedObject().ShouldEqual(actual);
3. composized object: expected.ToExpectedObject().ShouldEqual(actual);
4. partial compare: expected object need design with anonymous type, and use expected.ToExpectedObject().ShouldMatch(actual)

I love ExpectedObjects because of I only need to invoke 2 API for assertion of comparing object equality:

1. ShouldEqual()
2. ShouldMatch() for partial comparing

Answer 5

I wanted a solution that didn't require adding a dependency, worked with VS unit tests, compared the field values of two objects,and told me all unequal fields. This is what I came up with. Note it could be extended to work with property values as well.

In my case, this works well for comparing the results of some file-parsing logic to ensure two technically "different" entries have fields with the same values.

    public class AssertHelper
    {
        public static void HasEqualFieldValues<T>(T expected, T actual)
        {
            var failures = new List<string>();
            var fields = typeof(T).GetFields(System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.Instance);
            foreach(var field in fields)
            {
                var v1 = field.GetValue(expected);
                var v2 = field.GetValue(actual);
                if (v1 == null && v2 == null) continue;
                if(!v1.Equals(v2)) failures.Add(string.Format("{0}: Expected:<{1}> Actual:<{2}>", field.Name, v1, v2));
            }
            if (failures.Any())
                Assert.Fail("AssertHelper.HasEqualFieldValues failed. " + Environment.NewLine+ string.Join(Environment.NewLine, failures));
        }
    }

    [TestClass]
    public class AssertHelperTests
    {
        [TestMethod]     
        [ExpectedException(typeof(AssertFailedException))]           
        public void ShouldFailForDifferentClasses()
        {            
            var actual = new NewPaymentEntry() { acct = "1" };
            var expected = new NewPaymentEntry() { acct = "2" };
            AssertHelper.HasEqualFieldValues(expected, actual);
        }
    }

Answer 6

Since neither have yet been mentioned on this question, there are a couple of other well adopted libraries out there that can help with this problem:

1. Fluent Assertions - see object graph comparison

   actual.Should().BeEquivalentTo(expected);

2. Semantic Comparison

   Likeness<MyModel, MyModel>(actual).ShouldEqual(expected);

I personally prefer Fluent Assertions as provides greater flexibility with member exclusions etc and it supports the comparison of nested objects out of the box.

Hope this helps!

Answer 7

Assert methods rely on the object's Equals and GetHashcode. You can implement that, but if this object equality is not needed outside unit tests I would instead consider comparing the individual primitive types on the object. Looks like the objects are simple enough and overriding of equals is not really warranted.

Answer 8

If you want to compare only properties of a complex type object, Iterating over object properties will gives all the properties. You can try below code.

//Assert
foreach(PropertyInfo property in Object1.GetType().GetProperties())
{
    Assert.AreEqual(property.GetValue(Object1), property.GetValue(Object2));
}