Je préfère ne pas remplacer Equals juste pour permettre les tests. N'oubliez pas que si vous surchargez Equals, vous devez également surcharger GetHashCode, sinon vous risquez d'obtenir des résultats inattendus si vous utilisez vos objets dans un dictionnaire par exemple.
J'aime l'approche de réflexion ci-dessus, car elle tient compte de l'ajout de propriétés à l'avenir.
Cependant, pour une solution simple et rapide, il est souvent plus facile de créer une méthode d'aide qui teste si les objets sont égaux, ou d'implémenter IEqualityComparer dans une classe que vous gardez privée pour vos tests. Lorsque vous utilisez la solution IEqualityComparer, vous n'avez pas besoin de vous soucier de l'implémentation de GetHashCode. Par exemple :
// Sample class. This would be in your main assembly.
class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
// Unit tests
[TestFixture]
public class PersonTests
{
private class PersonComparer : IEqualityComparer<Person>
{
public bool Equals(Person x, Person y)
{
if (x == null && y == null)
{
return true;
}
if (x == null || y == null)
{
return false;
}
return (x.Name == y.Name) && (x.Age == y.Age);
}
public int GetHashCode(Person obj)
{
throw new NotImplementedException();
}
}
[Test]
public void Test_PersonComparer()
{
Person p1 = new Person { Name = "Tom", Age = 20 }; // Control data
Person p2 = new Person { Name = "Tom", Age = 20 }; // Same as control
Person p3 = new Person { Name = "Tom", Age = 30 }; // Different age
Person p4 = new Person { Name = "Bob", Age = 20 }; // Different name.
Assert.IsTrue(new PersonComparer().Equals(p1, p2), "People have same values");
Assert.IsFalse(new PersonComparer().Equals(p1, p3), "People have different ages.");
Assert.IsFalse(new PersonComparer().Equals(p1, p4), "People have different names.");
}
}
