Testen generische Sammlungen für referentielle Gleichheit in C # eine dumme Idee?

9

Ich implementiere einen speziellen Fall eines unveränderlichen Wörterbuchs, das aus praktischen Gründen IEnumerable<KeyValuePair<Foo, Bar>> implementiert. Operationen, die normalerweise das Wörterbuch ändern würden, sollten stattdessen eine neue Instanz zurückgeben.

So weit, so gut. Aber wenn ich versuche, einen flüssigen Einheitentest für die Klasse zu schreiben, stelle ich fest, dass keine der beiden fließenden Assertion-Bibliotheken, die ich ausprobiert habe ( Should und Fluent Assertions ) unterstützt die NotBeSameAs() -Operation für Objekte, die IEnumerable implementieren - nicht, solange Sie sie nicht zuerst umsetzen zu Object .

Als ich zum ersten Mal mit Should darauf stieß, nahm ich an, dass es nur ein Loch im Framework war, aber als ich sah, dass Fluent Assertions dasselbe Loch hatte, dachte ich, dass ich relativ neu bin zu C #) Ich könnte etwas konzeptionell über C # Sammlungen vermissen - der Autor von sollte so viel impliziert , als ich mich anmeldete ein Problem.

Natürlich gibt es andere Möglichkeiten, dies zu testen - in Object umwandeln und NotBeSameAs() verwenden, einfach Object.ReferenceEquals verwenden, was auch immer - aber wenn es einen guten Grund dafür gibt, würde ich gerne wissen, was das ist ist.

    
David Moles 13.03.2013, 14:53
quelle

2 Antworten

1

Ein IEnumerable<T> ist nicht notwendigerweise ein reales Objekt. IEnumerable<T> garantiert, dass Sie über seine Zustände aufzählen können. In einfachen Fällen haben Sie eine Container-Klasse wie zB List<T> , die bereits materialisiert ist. Dann könnten Sie die Adressen beider Listen vergleichen. Ihr IEnumerable<T> kann jedoch auch auf eine Befehlsfolge verweisen, die beim Aufzählen ausgeführt wird. Grundsätzlich eine Zustandsmaschine:

%Vor%

Wenn Sie das in einer Variablen speichern, haben Sie kein vergleichbares Objekt (alles ist ein Objekt, also tun Sie das ... aber es ist nicht sinnvoll):

%Vor%

Ihr Vergleich funktioniert nur für materialisierte ( .ToList() oder .ToArray() ) IEnumerables, da diese Statusmaschinen ausgewertet und ihre Ergebnisse in einer Sammlung gespeichert wurden. Also ja, die Bibliothek macht tatsächlich Sinn, wenn Sie wissen Sie IEnumerables materialisiert haben, müssen Sie dieses Wissen veröffentlichen, indem Sie sie auf Objekt übertragen und die gewünschte Funktion für dieses Objekt "manuell" aufrufen / p>     

nvoigt 13.03.2013, 16:24
quelle
1

Außerdem, was Jon Skeet vorgeschlagen hat, werfen Sie einen Blick auf diesen Februar 2013 MSDN-Artikel von Ted Neward:

.NET Collections, Teil 2: Arbeiten mit C5

  

Unveränderbare (geschützte) Sammlungen

     

Mit dem Aufkommen von funktionalen Konzepten   und Programmierstile, hat viel Betonung auf unveränderliche Daten geschwenkt   und unveränderliche Objekte, vor allem, weil unveränderliche Objekte viel bieten   Vorteile gegenüber Nebenläufigkeit und parallel Programmierung, sondern auch   weil viele Entwickler unveränderliche Objekte leichter zu verstehen finden   und Grund über. Folgerung aus diesem Konzept folgt dann dem Konzept   von unveränderlichen Sammlungen - die Idee, dass unabhängig davon, ob die   Objekte innerhalb der Sammlung sind unveränderlich, die Sammlung selbst ist   behoben und nicht in der Lage, die Elemente in der ändern (hinzufügen oder entfernen)   Sammlung. (Hinweis: Sie können eine Vorschau von unveränderbaren Sammlungen anzeigen   veröffentlicht in NuGet im MSDN Base Class Library (BCL) Blog unter    bit.ly/12AXD78 .)

Es beschreibt die Verwendung einer Open-Source-Bibliothek der Sammlung Güte namens C5. Schau dir Ссылка

an     
Petar Repac 13.03.2013 16:44
quelle