Gibt es in einem anderen Test eine Möglichkeit zur Wiederverwendung durch den N-Unit-Test?

Question

Ich weiß, die offensichtliche Antwort hier ist, [SetUp] verwenden, aber es gibt eine sehr reale Chance, dass der Code, der das Ergebnis erhält, eine Ausnahme auslösen konnte, und das möchten wir testen.

Haftungsausschluss im Voraus, wir machen keine "echten" Komponententests. Was wir machen, könnte am besten als Integrationstest beschrieben werden, das Design ist fertig, wir haben keine Unit Tests gemacht, wir haben nicht die Ressourcen, um sie jetzt zu machen, aber wir versuchen, eine automatische Abdeckung auf einem größeren zu bekommen Brocken von Funktionalität.

Ein solcher Chunk ist eine Funktion, die Daten aus einer externen Datenbank aggregiert und 4 komplexe Objekte mit verschiedenen Referenzen erstellt, die wir dann in mehreren Tabellen in unserer internen Datenbank speichern. Wir haben die Hauptaggregationsfunktion bereits umstrukturiert, um die Objekte in einer Wrapperklasse zurückzugeben (bevor die Aggregationsfunktion ebenfalls das Einfügen vorgenommen hat). Der Aufrufer führt nun das Einfügen durch. Dies ermöglicht es uns, automatisierte Tests zu schreiben, um die Daten automatisch zu validieren, ohne dass es kompliziert ist, sie wieder aus unserer Datenbank zu entfernen.

Das Problem ist, dass wir in NUnit diese Aggregationsfunktion testen möchten. Wir können es nicht detaillierter machen. Aber wir wollen jedes der 4 Objekte einzeln validieren und sicherstellen, dass die Funktion keine Ausnahmen erzeugt.

Die Funktion dauert ziemlich lange, um mit einem kleinen Satz zu laufen, so dass wir es vermeiden möchten, dasselbe Objekt 4 mal wiederholt auszuführen, um jedes Objekt zu testen.

Idealerweise möchten wir einen Test durchführen, um zu verifizieren, dass die Funktion ohne Fehler abgeschlossen ist-> dieses Ergebnis in die Validierung für ein komplexes Objekt einbringen-> komplexes Objekt-> und so weiter. Ist das mit NUnit möglich oder gibt es ein anderes Paradigma, das wir verwenden können?

Ich nehme an, dass wir im schlimmsten Fall die Aggregation viermal auf demselben Datensatz ausführen.

Answer 1

Da Sie keine „echten“ Unit-Tests tun schon, warum nicht nur einen einzigen „Wrapper“ Testfall erstellen, die eine Reihe von „Stufen“ in Folge ruft wie:

[Test] 
public void ShouldPassAllTests() 
{ 
    var result1 = Step1(); 
    var result2 = Step2(result1); 
    var result3 = Step3(result2); 
    Step4(result3); 
} 

private void Step1/2/3/4() 
{ 
    // Arrange Something 
    // Do Something 
    // Assert Something 
} 

Seine definitiv nicht ideal, aber zumindest stellen Sie sicher, dass Ihre Tests in der richtigen Reihenfolge ablaufen.

Wenn Sie mich fragen, würde ich versuchen, anstatt auf solche Dinge zurückgreifen, würde ich versuchen, für einige Zeit zu versuchen, um Ihren Code in etwas mehr testbar und schreiben richtige Tests von Anfang an.

Answer 2

Ich verstehe Ihr Zögern mit Tests im Setup und es ist sicherlich nicht für die meisten Unit-Testsituationen geeignet. Manchmal ist es jedoch nützlich und NUnit unterstützt es. Ein Assertionsfehler in einem Setup führt dazu, dass das Fixture fehlschlägt und alle Testmethoden ebenfalls als Fehler gemeldet werden.

[FWIW, was NUnit tut nicht Unterstützung Fehler in einem Teardown Jede Ausnahme in Teardown ist, auch SuccessException, verursacht einen Fehler.]

NUnit ein paar Tests von seiner eigenen hat, die als Einheit mehr funktionsfähig sind Tests und die dieses Muster verwenden. Das etwas kostspielige Laden einer Baugruppe erfolgt einmalig im OneTimeSetUp. Einige Behauptungen bestätigen, dass das Setup korrekt ausgeführt wurde. Anschließend werden verschiedene unabhängige Tests für die geladene Assembly ausgeführt.

Sie könnten das gleiche tun, indem Sie die Aggregationsfunktion in Ihrem OneTimeSetUp ausführen und vier verschiedene Tests durchführen, um die verschiedenen Aspekte zu überprüfen.

Stilistisch, sehe ich nichts falsch mit dieser Art zu testen, solange es nicht die einzige Art von Tests ist, die Sie für die Funktion tun. Wenn es wichtig ist, verdient es wahrscheinlich auch einige Komponententests.