Wie schreibt man eine Testmethode in NUnit zum Testen einer Savefile-Methode?

Question

Ich habe eine savefile-Methode geschrieben, um ein Objekt in xml zu speichern. Aber ich bin nicht sicher, wie ich die Methode in NUnit testen kann. Muss ich eine Beispieldatei manuell erstellen und den String zwischen den Dateien vergleichen? Gibt es eine bessere Möglichkeit, die Methode zu testen?

Vielen Dank für Ihre Antwort.

Answer 1

Igitt, XML-Ausgabe validieren. Willkommen in der Hölle :)

Eine Methode, die sich bei mir bewährt hat, war die Erstellung eines XmlDocument Objekt im Speicher. Führen Sie dann Ihre SaveFile-Methode aus, und laden Sie sie in ein anderes XmlDocument . Beide XmlDokumente rekursiv durchlaufen und dabei alle Elemente und Attribute vergleichen.

Leider ist das Schreiben von Xml mit C#-Objekten groß und sperrig. Ich würde empfehlen, Teilabschnitte auf einmal zu testen. Vielleicht hat Ihre Speicherdatei eine <FileList> Unterelement, ein <Cups> Unterelement, und <Rifles> Unterelement. Schreiben Sie in diesem Fall eine Reihe von Tests, um sicherzustellen, dass jeder Teilabschnitt korrekt ausgeführt wird, und nicht die Gesamtausgabe.

Answer 2

Es wäre einfacher, wenn Sie den Code zeigen würden. Mein Weg, dies zu umgehen, ist eine Abstraktionsebene hinzuzufügen. Lassen Sie Ihre Save-Methode nicht direkt mit XmlWriter arbeiten. Erstellen Sie stattdessen Wrapper, die jeweils in der Lage, kleine logische Brocken Ihrer Daten zu xml speichern, und testen Sie diese.

für jeden Wrapper eine Methode wie

void Persist(XmlWriter writer);

und lassen Sie Save einfach die Daten von den Wrappern sammeln. Mit anderen Worten, die Wrapper wären dafür verantwortlich, die Daten ordnungsgemäß zu speichern, aber jeder ist nur für einen kleinen Teil davon verantwortlich. Sie können dies testen, indem Sie Strings vergleichen (legen Sie StringWriter in XmlWriter, den Sie an die Persist-Methode übergeben)

Answer 3

Optionen

1. Vereinfacht: Verwenden Sie den Ansatz der "Goldenen Datei". Erstellen Sie eine schreibgeschützte erwartete Ausgabedatei als Ressource. Führen Sie einen byte-/stringweisen Vergleich mit der tatsächlich erzeugten Datei durch.
2. Ich habe gehört, dass einige Leute die XmlUnit zu diesem Zweck. Ich habe es nie persönlich benutzt, aber es könnte sich lohnen, einen Blick darauf zu werfen

Answer 4

Ich gehe folgendermaßen vor - bei mir funktioniert es, aber vielleicht entspricht es nicht Ihren Anforderungen.

Beim Teardown stelle ich sicher, dass ich alle Dateien lösche, die ich möglicherweise als Teil der Suite erstellt habe. Also ja, stellen Sie sicher, dass die Datei eine Scratch-Datei ist, die nur zum Testen dient.

In der Testmethode lösche ich die Datei, wenn sie vorhanden ist (das sollte nicht der Fall sein, da der Teardown sich bereits darum gekümmert hat), dann gebe ich die Datei in XML aus und stelle fest, dass die Datei vorhanden ist. Ich lade dann die Datei entweder in einen Objektgraphen oder in das XML-DOM und frage den Zustand durch so viele Assertions wie nötig ab.

Wenn Sie mit dem Schreiben in Dateien auskommen und Ihr Design es Ihnen erlaubt, in einen generischen Text- oder Xml-Writer zu schreiben, dann können Sie die Dateispeicherung umgehen und stattdessen die Aufrufe durch einen String-Writer ersetzen und einfach einen String abfragen. Viel sauberer, aber es nicht testen, dass die tatsächliche Datei Persistenz funktioniert oder nicht.

Answer 5

Entwerfen Sie Ihre Klasse so, dass Sie SaveFile( string fileName ) und SaveFile( XmlWriter writer) haben. SaveFile( string filename ) muss nur einen XmlWriter für die benannte Datei erstellen und SaveFile( writer ) aufrufen. Führen Sie umfangreiche Unit-Tests für die Methode SaveFile( XmlWriter writer ) durch, für die Sie einen Mock XmlWriter verwenden können. Testen Sie einige Fehlerbedingungen - wenn Sie erwarten, sie zu behandeln, anstatt sie weiterzugeben - mit der Methode SaveFile( string filename ). Abhängig von der Fehlerbehandlung müssen Sie möglicherweise gar keine Datei erstellen.

Übrigens müssen Sie Ihre Methode nicht direkt mit dem XmlWriter offenlegen, wenn Sie das nicht wollen. Sie können sie privat machen und einen Accessor verwenden, um sie in Ihren Tests aufzurufen.