it-swarm.com.de

Vergleichen Sie die Gleichheit zwischen zwei Objekten in NUnit

Ich versuche zu behaupten, dass ein Objekt einem anderen Objekt "gleich" ist. 

Bei den Objekten handelt es sich lediglich um Instanzen einer Klasse mit einer Reihe öffentlicher Eigenschaften. Gibt es eine einfache Möglichkeit, NUnit auf der Grundlage der Eigenschaften Gleichheit durchzusetzen?

Dies ist meine aktuelle Lösung, aber ich denke, dass es vielleicht etwas Besseres gibt:

Assert.AreEqual(LeftObject.Property1, RightObject.Property1)
Assert.AreEqual(LeftObject.Property2, RightObject.Property2)
Assert.AreEqual(LeftObject.Property3, RightObject.Property3)
...
Assert.AreEqual(LeftObject.PropertyN, RightObject.PropertyN)

Was ich anstrebe, würde im selben Sinne wie die CollectionEquivalentConstraint sein, wobei NUnit überprüft, ob der Inhalt zweier Sammlungen identisch ist.

112
Michael Haren

Überschreiben Sie .Equals für Ihr Objekt und im Komponententest können Sie einfach Folgendes tun:

Assert.AreEqual(LeftObject, RightObject);

Natürlich kann dies bedeuten, dass Sie einfach alle einzelnen Vergleiche auf die .Equals-Methode verschieben, aber Sie können die Implementierung für mehrere Tests wiederverwenden. Möglicherweise ist es sinnvoll, wenn sich Objekte sowieso mit Geschwistern vergleichen lassen.

Wenn Sie Equals aus irgendeinem Grund nicht überschreiben können, können Sie eine Hilfsmethode erstellen, die öffentliche Eigenschaften durch Reflektion durchläuft und jede Eigenschaft bestätigt. Etwas wie das:

public static class AssertEx
{
    public static void PropertyValuesAreEquals(object actual, object expected)
    {
        PropertyInfo[] properties = expected.GetType().GetProperties();
        foreach (PropertyInfo property in properties)
        {
            object expectedValue = property.GetValue(expected, null);
            object actualValue = property.GetValue(actual, null);

            if (actualValue is IList)
                AssertListsAreEquals(property, (IList)actualValue, (IList)expectedValue);
            else if (!Equals(expectedValue, actualValue))
                Assert.Fail("Property {0}.{1} does not match. Expected: {2} but was: {3}", property.DeclaringType.Name, property.Name, expectedValue, actualValue);
        }
    }

    private static void AssertListsAreEquals(PropertyInfo property, IList actualList, IList expectedList)
    {
        if (actualList.Count != expectedList.Count)
            Assert.Fail("Property {0}.{1} does not match. Expected IList containing {2} elements but was IList containing {3} elements", property.PropertyType.Name, property.Name, expectedList.Count, actualList.Count);

        for (int i = 0; i < actualList.Count; i++)
            if (!Equals(actualList[i], expectedList[i]))
                Assert.Fail("Property {0}.{1} does not match. Expected IList with element {1} equals to {2} but was IList with element {1} equals to {3}", property.PropertyType.Name, property.Name, expectedList[i], actualList[i]);
    }
}
114
Juanma

Überschreiben Sie Equals nicht nur zu Testzwecken. Es ist langweilig und wirkt sich auf die Domänenlogik aus.

Verwenden Sie JSON, um die Daten des Objekts zu vergleichen

Keine zusätzliche Logik für Ihre Objekte. Keine zusätzlichen Aufgaben zum Testen. 

Verwenden Sie einfach diese einfache Methode:

public static void AreEqualByJson(object expected, object actual)
{
    var serializer = new System.Web.Script.Serialization.JavaScriptSerializer();
    var expectedJson = serializer.Serialize(expected);
    var actualJson = serializer.Serialize(actual);
    Assert.AreEqual(expectedJson, actualJson);
}

Es scheint gut zu klappen. In den Test Runner Results-Informationen wird der JSON-Zeichenfolgenvergleich (der Objektgraph) angezeigt, sodass Sie direkt sehen, was falsch ist.

Beachten Sie auch! Wenn Sie größere komplexe Objekte haben und nur Teile davon vergleichen möchten, können Sie (LINQ für Sequenzdaten verwenden) anonyme Objekte erstellen, die mit der oben genannten Methode verwendet werden.

public void SomeTest()
{
    var expect = new { PropA = 12, PropB = 14 };
    var sut = loc.Resolve<SomeSvc>();
    var bigObjectResult = sut.Execute(); // This will return a big object with loads of properties 
    AssExt.AreEqualByJson(expect, new { bigObjectResult.PropA, bigObjectResult.PropB });
}
94
Max Wikstrom

Testen Sie die FluentAssertions-Bibliothek:

dto.ShouldHave(). AllProperties().EqualTo(customer);

http://www.fluentassertions.com/

Es kann auch mit NuGet installiert werden.

79
dkl

Ich ziehe es vor, Equals nicht zu überschreiben, nur um Tests zu ermöglichen. Vergessen Sie nicht, dass Sie auch GetHashCode überschreiben sollten, wenn Sie Equals überschreiben. Andernfalls erhalten Sie möglicherweise unerwartete Ergebnisse, wenn Sie beispielsweise Ihre Objekte in einem Wörterbuch verwenden.

Ich mag den Reflexionsansatz oben, da er in der Zukunft das Hinzufügen von Eigenschaften ermöglicht.

Für eine schnelle und einfache Lösung ist es jedoch oft am einfachsten, entweder eine Hilfsmethode zu erstellen, die testet, ob die Objekte gleich sind, oder IEqualityComparer in einer Klasse zu implementieren, die Sie für Ihre Tests privat halten. Wenn Sie die IEqualityComparer-Lösung verwenden, müssen Sie sich nicht um die Implementierung von GetHashCode kümmern. Zum Beispiel:

// 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.");
    }
}
34
Chris Yoxall

Ich habe mehrere hier erwähnte Ansätze ausprobiert. In den meisten Fällen werden Ihre Objekte serialisiert und ein Zeichenkettenvergleich durchgeführt. Obwohl es sehr einfach und im Allgemeinen sehr effektiv ist, habe ich festgestellt, dass es kurz ist, wenn Sie einen Fehler haben und etwas Ähnliches gemeldet wird:

Expected string length 2326 but was 2342. Strings differ at index 1729.

Herauszufinden, wo die Unterschiede sind, ist ein Schmerz, um es gelinde auszudrücken.

Mit den Objektgraphen-Vergleichen von FluentAssertions (d. H. a.ShouldBeEquivalentTo(b)) erhalten Sie Folgendes zurück:

Expected property Name to be "Foo" but found "Bar"

Das ist viel schöner. Holen Sie sich FluentAssertions Jetzt werden Sie sich später freuen (und falls Sie dies bestätigen, bestätigen Sie bitte auch Antwort von Dkl wo FluentAssertions zuerst vorgeschlagen wurde).

13
Todd Menier

Ich stimme mit ChrisYoxall überein - die Implementierung von Equals zu Testzwecken in Ihrem Hauptcode ist nicht gut.

Wenn Sie Equals implementieren, weil einige Anwendungslogik dies erfordert, ist das in Ordnung, aber halten Sie reinen Test-Code aus dem Durcheinander.

Kurz gesagt, halten Sie nur Test-Code außerhalb Ihrer Klasse.

Ein einfacher flacher Vergleich von Eigenschaften mithilfe von Reflektionen sollte für die meisten Klassen ausreichen. Sie müssen jedoch möglicherweise erneut suchen, wenn Ihre Objekte komplexe Eigenschaften aufweisen. Beachten Sie bei Verweisen auf Zirkelverweise oder ähnliches.

Schlau

9
Sly Gryphon

Eigenschaftsbeschränkungen , hinzugefügt in NUnit 2.4.2, ermöglichen eine Lösung, die besser lesbar ist als die ursprüngliche Lösung des OP und es werden wesentlich bessere Fehlermeldungen angezeigt. Es ist in keiner Weise generisch, aber wenn Sie es nicht für zu viele Klassen tun müssen, ist dies eine sehr angemessene Lösung.

Assert.That(ActualObject, Has.Property("Prop1").EqualTo(ExpectedObject.Prop1)
                          & Has.Property("Prop2").EqualTo(ExpectedObject.Prop2)
                          & Has.Property("Prop3").EqualTo(ExpectedObject.Prop3)
                          // ...

Nicht so allgemein wie das Implementieren von Equals, aber es gibt eine viel bessere Fehlermeldung als

Assert.AreEqual(ExpectedObject, ActualObject);
4
Paul Hicks

Die JSON-Lösung von Max Wikstrom (oben) ist für mich am sinnvollsten. Sie ist kurz, sauber und vor allem funktioniert sie. Ich persönlich bevorzuge es, die JSON-Konvertierung als separate Methode zu implementieren und den Assert so wieder in den Unit-Test zu setzen ...

HELPER-VERFAHREN:

public string GetObjectAsJson(object obj)
    {
        System.Web.Script.Serialization.JavaScriptSerializer oSerializer = new System.Web.Script.Serialization.JavaScriptSerializer();
        return oSerializer.Serialize(obj);
    }

GERÄTETEST :

public void GetDimensionsFromImageTest()
        {
            Image Image = new Bitmap(10, 10);
            ImageHelpers_Accessor.ImageDimensions expected = new ImageHelpers_Accessor.ImageDimensions(10,10);

            ImageHelpers_Accessor.ImageDimensions actual;
            actual = ImageHelpers_Accessor.GetDimensionsFromImage(Image);

            /*USING IT HERE >>>*/
            Assert.AreEqual(GetObjectAsJson(expected), GetObjectAsJson(actual));
        }

Zu Ihrer Information - Möglicherweise müssen Sie einen Verweis auf System.Web.Extensions in Ihrer Lösung hinzufügen.

3
samaspin

Dies ist ein ziemlich alter Thread, aber ich frage mich, ob es einen Grund gibt, warum keine Antwort vorgeschlagen wurde NUnit.Framework.Is.EqualTo und NUnit.Framework.Is.NotEqualTo?

Sowie:

Assert.That(LeftObject, Is.EqualTo(RightObject)); 

und

Assert.That(LeftObject, Is.Not.EqualTo(RightObject)); 
1
user2315856

Installieren Sie einfach ExpectedObjects von Nuget aus. Sie können den Eigenschaftenwert von zwei Objekten, jeden Objektwert der Auflistung, den Wert von zwei zusammengesetzten Objekten und den Vergleichswert des teilweisen Objekts nach anonymen Typen einfach vergleichen.

Ich habe einige Beispiele für github: https://github.com/hatelove/CompareObjectEquals

Hier einige Beispiele, die Szenarien des Objektvergleichs enthalten:

    [TestMethod]
    public void Test_Person_Equals_with_ExpectedObjects()
    {
        //use extension method ToExpectedObject() from using ExpectedObjects namespace to project Person to ExpectedObject
        var expected = new Person
        {
            Id = 1,
            Name = "A",
            Age = 10,
        }.ToExpectedObject();

        var actual = new Person
        {
            Id = 1,
            Name = "A",
            Age = 10,
        };

        //use ShouldEqual to compare expected and actual instance, if they are not equal, it will throw a System.Exception and its message includes what properties were not match our expectation.
        expected.ShouldEqual(actual);
    }

    [TestMethod]
    public void Test_PersonCollection_Equals_with_ExpectedObjects()
    {
        //collection just invoke extension method: ToExpectedObject() to project Collection<Person> to ExpectedObject too
        var expected = new List<Person>
        {
            new Person { Id=1, Name="A",Age=10},
            new Person { Id=2, Name="B",Age=20},
            new Person { Id=3, Name="C",Age=30},
        }.ToExpectedObject();

        var actual = new List<Person>
        {
            new Person { Id=1, Name="A",Age=10},
            new Person { Id=2, Name="B",Age=20},
            new Person { Id=3, Name="C",Age=30},
        };

        expected.ShouldEqual(actual);
    }

    [TestMethod]
    public void Test_ComposedPerson_Equals_with_ExpectedObjects()
    {
        //ExpectedObject will compare each value of property recursively, so composed type also simply compare equals.
        var expected = new Person
        {
            Id = 1,
            Name = "A",
            Age = 10,
            Order = new Order { Id = 91, Price = 910 },
        }.ToExpectedObject();

        var actual = new Person
        {
            Id = 1,
            Name = "A",
            Age = 10,
            Order = new Order { Id = 91, Price = 910 },
        };

        expected.ShouldEqual(actual);
    }

    [TestMethod]
    public void Test_PartialCompare_Person_Equals_with_ExpectedObjects()
    {
        //when partial comparing, you need to use anonymous type too. Because only anonymous type can dynamic define only a few properties should be assign.
        var expected = new
        {
            Id = 1,
            Age = 10,
            Order = new { Id = 91 }, // composed type should be used anonymous type too, only compare properties. If you trace ExpectedObjects's source code, you will find it invoke config.IgnoreType() first.
        }.ToExpectedObject();

        var actual = new Person
        {
            Id = 1,
            Name = "B",
            Age = 10,
            Order = new Order { Id = 91, Price = 910 },
        };

        // partial comparing use ShouldMatch(), rather than ShouldEqual()
        expected.ShouldMatch(actual);
    }

Referenz:

  1. ExpectedObjects github
  2. Einführung von ExpectedObjects
1
In91

https://github.com/kbilsted/StatePrinter wurde speziell geschrieben, um Objektdiagramme in die String-Darstellung zu kopieren, um einfache Unit-Tests zu schreiben. 

  • Es gibt Assert-Methoden, die einen korrekt maskierten String zum Kopieren und Einfügen in den Test ausgeben, um ihn zu korrigieren.
  • Es ermöglicht, dass unittest automatisch neu geschrieben wird
  • Es lässt sich in alle Gerätetest-Frameworks integrieren
  • Im Gegensatz zur JSON-Serialisierung werden Zirkelverweise unterstützt
  • Sie können leicht filtern, sodass nur Teile der Typen abgelegt werden

Gegeben

class A
{
  public DateTime X;
  public DateTime Y { get; set; }
  public string Name;
}

Sie können in typensicherer Weise Felder einschließen oder ausschließen, wenn Sie die automatische Vervollständigung von Visual Studio verwenden. 

  var printer = new Stateprinter();
  printer.Configuration.Projectionharvester().Exclude<A>(x => x.X, x => x.Y);

  var sut = new A { X = DateTime.Now, Name = "Charly" };

  var expected = @"new A(){ Name = ""Charly""}";
  printer.Assert.PrintIsSame(expected, sut);
1
Carlo V. Dango

Eine weitere Option ist das Schreiben einer benutzerdefinierten Einschränkung durch Implementierung der abstrakten NUnit-Klasse Constraint. Mit einer Hilfsklasse, die etwas syntaktischen Zucker liefert, ist der resultierende Testcode angenehm knapp und lesbar, z. 

Assert.That( LeftObject, PortfolioState.Matches( RightObject ) ); 

Ein extremes Beispiel ist die Klasse mit schreibgeschützten Mitgliedern. Dies ist nicht IEquatable. Sie können die zu testende Klasse auch nicht ändern, wenn Sie Folgendes möchten:

public class Portfolio // Somewhat daft class for pedagogic purposes...
{
    // Cannot be instanitated externally, instead has two 'factory' methods
    private Portfolio(){ }

    // Immutable properties
    public string Property1 { get; private set; }
    public string Property2 { get; private set; }  // Cannot be accessed externally
    public string Property3 { get; private set; }  // Cannot be accessed externally

    // 'Factory' method 1
    public static Portfolio GetPortfolio(string p1, string p2, string p3)
    {
        return new Portfolio() 
        { 
            Property1 = p1, 
            Property2 = p2, 
            Property3 = p3 
        };
    }

    // 'Factory' method 2
    public static Portfolio GetDefault()
    {
        return new Portfolio() 
        { 
            Property1 = "{{NONE}}", 
            Property2 = "{{NONE}}", 
            Property3 = "{{NONE}}" 
        };
    }
}

Der Vertrag für die Constraint-Klasse erfordert, dass Sie Matches und WriteDescriptionTo überschreiben (im Falle einer Nichtübereinstimmung eine Erzählung für den erwarteten Wert), aber auch die Überschreibung von WriteActualValueTo (Erzählung für den tatsächlichen Wert) macht Sinn:

public class PortfolioEqualityConstraint : Constraint
{
    Portfolio expected;
    string expectedMessage = "";
    string actualMessage = "";

    public PortfolioEqualityConstraint(Portfolio expected)
    {
        this.expected = expected;
    }

    public override bool Matches(object actual)
    {
        if ( actual == null && expected == null ) return true;
        if ( !(actual is Portfolio) )
        { 
            expectedMessage = "<Portfolio>";
            actualMessage = "null";
            return false;
        }
        return Matches((Portfolio)actual);
    }

    private bool Matches(Portfolio actual)
    {
        if ( expected == null && actual != null )
        {
            expectedMessage = "null";
            expectedMessage = "non-null";
            return false;
        }
        if ( ReferenceEquals(expected, actual) ) return true;

        if ( !( expected.Property1.Equals(actual.Property1)
                 && expected.Property2.Equals(actual.Property2) 
                 && expected.Property3.Equals(actual.Property3) ) )
        {
            expectedMessage = expected.ToStringForTest();
            actualMessage = actual.ToStringForTest();
            return false;
        }
        return true;
    }

    public override void WriteDescriptionTo(MessageWriter writer)
    {
        writer.WriteExpectedValue(expectedMessage);
    }
    public override void WriteActualValueTo(MessageWriter writer)
    {
        writer.WriteExpectedValue(actualMessage);
    }
}

Plus die Helferklasse:

public static class PortfolioState
{
    public static PortfolioEqualityConstraint Matches(Portfolio expected)
    {
        return new PortfolioEqualityConstraint(expected);
    }

    public static string ToStringForTest(this Portfolio source)
    {
        return String.Format("Property1 = {0}, Property2 = {1}, Property3 = {2}.", 
            source.Property1, source.Property2, source.Property3 );
    }
}

Verwendungsbeispiel:

[TestFixture]
class PortfolioTests
{
    [Test]
    public void TestPortfolioEquality()
    {
        Portfolio LeftObject 
            = Portfolio.GetDefault();
        Portfolio RightObject 
            = Portfolio.GetPortfolio("{{GNOME}}", "{{NONE}}", "{{NONE}}");

        Assert.That( LeftObject, PortfolioState.Matches( RightObject ) );
    }
}
1
onedaywhen

Ich würde auf die Antwort von @Juanma bauen. Ich glaube jedoch, dass dies nicht mit Unit-Test-Assertions implementiert werden sollte. Dies ist ein Dienstprogramm, das unter Umständen von Nicht-Testcode verwendet werden kann. 

Ich schrieb einen Artikel über die Angelegenheit http://timoch.com/blog/2013/06/unit-test-equality-is-not-domain-equality/

Mein Vorschlag ist wie folgt:

/// <summary>
/// Returns the names of the properties that are not equal on a and b.
/// </summary>
/// <param name="a"></param>
/// <param name="b"></param>
/// <returns>An array of names of properties with distinct 
///          values or null if a and b are null or not of the same type
/// </returns>
public static string[] GetDistinctProperties(object a, object b) {
    if (object.ReferenceEquals(a, b))
        return null;
    if (a == null)
        return null;
    if (b == null)
        return null;

    var aType = a.GetType();
    var bType = b.GetType();

    if (aType != bType)
        return null;

    var props = aType.GetProperties();

    if (props.Any(prop => prop.GetIndexParameters().Length != 0))
        throw new ArgumentException("Types with index properties not supported");

    return props
        .Where(prop => !Equals(prop.GetValue(a, null), prop.GetValue(b, null)))
        .Select(prop => prop.Name).ToArray();
} 

Verwenden Sie dies mit NUnit

Expect(ReflectionUtils.GetDistinctProperties(tile, got), Empty);

ergibt die folgende Meldung bei Nichtübereinstimmung.

Expected: <empty>
But was:  < "MagmaLevel" >
at NUnit.Framework.Assert.That(Object actual, IResolveConstraint expression, String message, Object[] args)
at Undermine.Engine.Tests.TileMaps.BasicTileMapTests.BasicOperations() in BasicTileMapTests.cs: line 29
1
TiMoch

Schauen Sie sich den folgenden Link an. Es ist eine Lösung von Code Project und ich habe es auch verwendet. Es funktioniert gut für den Vergleich der Objekte.

http://www.codeproject.com/Articles/22709/Testing-Eualität-von-Zwei-objekten?msg=5189539#xx5189539xx

1
kanika

Ich weiß, dass dies eine wirklich alte Frage ist, aber NUnit hat noch keine native Unterstützung dafür. Wenn Sie BDD-ähnliche Tests (ala Jasmine) mögen, sind Sie mit NExpect ( https://github.com/fluffynuts/NExpect , erhalten Sie von NuGet) angenehm überrascht, das tiefe Gleichheitstests bietet genau dort gebacken.

(Haftungsausschluss: Ich bin der Autor von NExpect)

0
daf

Deserialisieren Sie beide Klassen und führen Sie einen Zeichenfolgenvergleich durch.

EDIT: Funktioniert perfekt, dies ist die Ausgabe, die ich von NUnit bekomme;

Test 'Telecom.SDP.SBO.App.Customer.Translator.UnitTests.TranslateEaiCustomerToDomain_Tests.TranslateNew_GivenEaiCustomer_ShouldTranslateToDomainCustomer_Test("ApprovedRatingInDb")' failed:
  Expected string length 2841 but was 5034. Strings differ at index 443.
  Expected: "...taClasses" />\r\n  <ContactMedia />\r\n  <Party i:nil="true" /..."
  But was:  "...taClasses" />\r\n  <ContactMedia>\r\n    <ContactMedium z:Id="..."
  ----------------------------------------------^
 TranslateEaiCustomerToDomain_Tests.cs(201,0): at Telecom.SDP.SBO.App.Customer.Translator.UnitTests.TranslateEaiCustomerToDomain_Tests.Assert_CustomersAreEqual(Customer expectedCustomer, Customer actualCustomer)
 TranslateEaiCustomerToDomain_Tests.cs(114,0): at Telecom.SDP.SBO.App.Customer.Translator.UnitTests.TranslateEaiCustomerToDomain_Tests.TranslateNew_GivenEaiCustomer_ShouldTranslateToDomainCustomer_Test(String custRatingScenario)

EDIT TWO: Die beiden Objekte können identisch sein, aber die Reihenfolge, in der Eigenschaften serialisiert werden, ist nicht dieselbe. Daher ist das XML anders. DOH!

EDIT THREE: Das funktioniert. Ich verwende es in meinen Tests. Sie müssen jedoch Elemente zu Auflistungseigenschaften in der Reihenfolge hinzufügen, in der der zu testende Code sie hinzufügt.

0
Casey Burns

Ich habe mit dem Schreiben einer einfachen Ausdrucksfabrik geendet:

public static class AllFieldsEqualityComprision<T>
{
    public static Comparison<T> Instance { get; } = GetInstance();

    private static Comparison<T> GetInstance()
    {
        var type = typeof(T);
        ParameterExpression[] parameters =
        {
            Expression.Parameter(type, "x"),
            Expression.Parameter(type, "y")
        };
        var result = type.GetProperties().Aggregate<PropertyInfo, Expression>(
            Expression.Constant(true),
            (acc, prop) =>
                Expression.And(acc,
                    Expression.Equal(
                        Expression.Property(parameters[0], prop.Name),
                        Expression.Property(parameters[1], prop.Name))));
        var areEqualExpression = Expression.Condition(result, Expression.Constant(0), Expression.Constant(1));
        return Expression.Lambda<Comparison<T>>(areEqualExpression, parameters).Compile();
    }
}

und benutze es einfach:

Assert.That(
    expectedCollection, 
    Is.EqualTo(actualCollection)
      .Using(AllFieldsEqualityComprision<BusinessCategoryResponse>.Instance));

Das ist sehr nützlich, da ich die Sammlung solcher Objekte vergleichen muss. Und Sie können diesen Vergleicher woanders verwenden :)

Hier ist Gist mit Beispiel: https://Gist.github.com/Pzixel/b63fea074864892f9aba8ffde312094f

0
Alex Zhukovskiy

Stringify und vergleichen Sie zwei Strings

Assert.AreEqual (JSON.stringify (LeftObject), JSON.stringify (RightObject))

0
jmtt89