Abschließend

Dies ist ein Auszug aus dem Unit Testing Succinctly eBook von Marc Clifton, freundlicherweise von Syncfusion zur Verfügung gestellt.

Unit-Tests sind auch für andere Zwecke von Nutzen.

Als Verwendungsbeispiele

Einer der Nebeneffekte des Unit-Tests besteht darin, dass eine große Codebasis erstellt wird, die die Verwendung des Codes veranschaulicht. Zum Beispiel den Code, den wir zuvor gesehen haben:

[Test] public void FilenameParsingTest () Wörterbuch options = CommandLineParser.Parse ("- f foobar"); Bestätigen Sie das (options.Count == 1, "Anzahl erwartet 1")); Assert.That (options.ContainsKey ("- f"), "Erwartete Option '-f" "); Assert.That (Optionen ["- f"] == "foobar");

dokumentiert einen erwarteten gültigen Anwendungsfall für den Befehlszeilen-Parser. Erwägen Sie auch das Schreiben von Unit-Tests - nicht nur für Ihren eigenen Code, sondern auch, um Beispiele für Bibliotheken von Drittanbietern bereitzustellen. (Siehe nachfolgende Beispiele und die interessanten Dinge über die Rechteckstruktur.)

Black Box Testing

Beim Black-Box-Test wird davon ausgegangen, dass Sie nichts über die internen Komponenten der Klasse oder des Dienstes wissen und das Verhalten streng anhand der öffentlich zugänglichen Schnittstellen überprüfen. Dies ist häufig erforderlich, wenn der Code nicht verfügbar ist. Bei der Arbeit mit einer Datensatzverwaltungsfirma mussten wir zum Beispiel einen von einer Regierungsbehörde bereitgestellten Web-Service verwenden, um die Datensätze zu aktualisieren. Durch das Schreiben von Komponententests für den Webservice konnten wir nachweisen, dass die uns zur Verfügung gestellte Dokumentation nicht zu dem erwarteten Verhalten des Webservice führte.

Sie können diese Technik auch verwenden, wenn Sie mit Code arbeiten, der von verschiedenen Abteilungen bereitgestellt wird. Beispielsweise kann die Datenbankgruppe über einen eigenen White-Box-Einheitentest verfügen. Sie sollten jedoch auch sicherstellen, dass die Trigger und Einschränkungen aus einer Black-Box-Perspektive korrekt programmiert wurden, indem Sie das Ergebnis von Transaktionen anhand der Ihnen zur Verfügung stehenden Funktionalität prüfen.

Testen Sie Ihre Annahmen

Unit-Tests können eine einfache Methode sein, um einige Tests bezüglich unserer Annahmen zu einer API zusammenzustellen. Nehmen wir die System.Drawing.Rectangle strukturieren und testen Sie einige scheinbar vernünftige Annahmen über die Implementierung.

Annahmen des Testkonstruktors

Es gibt zwei Rechteck Konstrukteure: einer mit Punkt und Größe die anderen Parameter haben die Parameter x, y, Breite und Höhe. Die Dokumentation gibt keinen Hinweis darauf, ob die Größe (die Breite oder Höhe) positiv sein muss. Schreiben wir also einen Test, um zu überprüfen, ob wir ein Rechteck mit negativer Breite oder Höhe konstruieren können:

[TestMethod] public void RectangleNegativeSizeConstructorTest () Rectangle r = new Rectangle (0, 0, -4, -6);

In diesem Test überprüfen wir lediglich, dass beim Konstruieren des Rechtecks keine Ausnahmen ausgelöst werden. Dies ist in der Tat der Fall:

Test für den Rechteckkonstruktor

Testannahmen hinsichtlich der Eigenschaftswerte

Lassen Sie uns nun unsere Annahmen über bestimmte Eigenschaften testen. Die Eigenschaften oben, Links, Unterseite, und Recht werden beschrieben als (siehe
http://msdn.microsoft.com/de-de/library/system.drawing.rectangle.aspx):

Oben: Ruft die y-Koordinate der oberen Kante dieser Rechteckstruktur ab.

Left: Ruft die X-Koordinate der linken Kante dieser Rectangle-Struktur ab.

Bottom: Ruft die y-Koordinate ab, die sich aus der Summe der Y- und Height-Eigenschaftswerte dieser Rechteckstruktur ergibt.

Right: Ruft die X-Koordinate ab, die sich aus der Summe der X- und Width-Eigenschaftswerte dieser Rechteckstruktur ergibt.

Bei dem vorhergehenden Rechteck mit negativer Breite und Höhe und mit den Koordinaten [(-4, -6), (0, 0)] würden wir daher folgende Annahmen treffen:

[TestMethod] public void TestLeft () Rechteck r = neues Rechteck (0, 0, -4, -6); Assert.IsTrue (r.Left == -4, "Erwartete Links == -4, war aber" + r.Left);  [TestMethod] public void TestTop () Rechteck r = neues Rechteck (0, 0, -4, -6); Assert.IsTrue (r.Top == 0, "Expected Top == 0, war aber" + r.Top);  [TestMethod] public void TestRight () Rechteck r = neues Rechteck (0, 0, -4, -6); Assert.IsTrue (r.Right == 0, "Expected Right == 0, war aber" + r.Right);  [TestMethod] public void TestBottom () Rechteck r = neues Rechteck (0, 0, -4, -6); Assert.IsTrue (r.Bottom == -6, "Expected Bottom == -6, war aber" + r.Bottom);

Dies ist jedoch nicht der Fall:

Annahmen über Rechteckeigenschaften testen

Tatsächlich erscheint die Bestimmung von oben und unten ebenfalls völlig willkürlich, da ich Tests mit exakt denselben Rechteckdimensionen durchführte und unterschiedliche Ergebnisse in der Ansicht beobachtete oben und Unterseite Eigenschaftswerte.

Annahmen über Methodenergebnisse prüfen

Die MSDN-Dokumentation gibt an, dass das Rectangle.Intersect Methode:

Gibt eine dritte Rechteckstruktur zurück, die den Schnittpunkt von zwei anderen Rechteckstrukturen darstellt.
Wenn keine Kreuzung vorhanden ist, wird ein leeres Rechteck zurückgegeben.

Daher können wir einen einfachen Test erstellen:

[TestMethod] public void TestIntersection () Rechteck r1 = neues Rechteck (0, 0, 10, 10); Rechteck r2 = neues Rechteck (10, 10, 5, 5); Assert.IsFalse (r1.IntersectsWith (r2) "Erwartet, dass sich R1 und R2 nicht schneiden."); Assert.IsTrue (Rectangle.Intersect (r1, r2) == Rectangle.Empty, "Ein leeres Schnittrechteck erwartet.");

mit dem Ergebnis:

Testen unserer Annahmen über Methodenrückgaben

Dies teilt uns mit, dass unsere Erwartungen aufgrund der Dokumentation falsch sind.

Abschließend

Komponententests sind ein wichtiges Werkzeug im Testprozess. Während Integrations- und Usability-Tests oft kundenorientierter sind (Berichterstellung, Meilensteine, Überprüfung der Anforderungen auf hohem Niveau), ist der Unit-Test die erste Verteidigungslinie für Programmierer, sein Team und die Teammanager. Bei vernünftiger Verwendung (denken Sie daran, Sie zielen nicht darauf ab, Tausende von grünen Ampeln zu erzeugen), kann dies eine kostengünstige Möglichkeit sein, die rechnerische Korrektheit des Codes zu überprüfen, Fehler erneut zu erstellen und zu überprüfen, ob sie behoben wurden.

Gute Unit-Test-Praktiken erfordern jedoch einen disziplinierten Ansatz, eine Verpflichtung zu Zeit und Aufwand, um die Tests zu implementieren und aufrechtzuerhalten, und aus Sicht des Codierers sind auch gute Programmierpraktiken erforderlich, und oft müssen architektonische Entscheidungen erzwungen werden. Letztere kann angesichts von Einschränkungen, die nur "erledigen" sind (was durchaus legitim sein kann) vorbeugen und möglicherweise die Leistung beeinträchtigen. Auf der anderen Seite sind die Programmierpraktiken und -architekturen, die von Unit-Tests erzwungen werden müssen, für den gesamten Anwendungsentwicklungsprozess oft von großem Nutzen. Dadurch werden Kosten gesenkt und die Wartbarkeit verbessert, nicht weil der Code Unit-Tests ist, sondern weil der Code besser geschrieben wird So das ist es können Gerät getestet werden.

Code