Die Fähigkeit, gute Komponententests zu schreiben, ist ein wichtiges Merkmal eines jeden Entwicklers. Aber wie können Sie verstehen, dass Ihre Unit-Tests korrekt sind? Ein guter Unit-Test ist wie ein gutes Schachspiel. In unserem Fall sind Schachfiguren die Ansätze, die wir in diesem Beitrag diskutieren werden. Es gibt keinen besten Schachspieler in einem Schachspiel, da alles von den Positionen (und einem Spieler) abhängt. Ebenso müssen Sie beim Unit-Test nicht nur einen Ansatz unterscheiden. Mit anderen Worten, Sie sollten alle Ansätze zusammen verwenden, um das beste Ergebnis zu erzielen. Also, wenn Sie dieses Spiel gewinnen möchten, dann begrüßen Sie unter dem Schnitt.
Debüt
Warum sollte ich Unit-Tests schreiben?
Sie müssen keine Komponententests schreiben, es sei denn, Sie sind eine Person mit außersinnlicher Wahrnehmung, die Code ohne Fehler schreiben kann, Sie haben ein super Gedächtnis, können Ihren Code in Ihrem Kopf kompilieren oder Sie mögen einfach nur Schmerz. Andernfalls müssen Sie auf jeden Fall Komponententests schreiben, da diese die Anzahl der Fehler in neuen und vorhandenen Funktionen verringern, die Kosten und die Angst vor Änderungen Ihrer Funktionen verringern und die Umgestaltung Ihres Codes ermöglichen. Darüber hinaus sollten Sie immer vorhandene Tests durchführen, und ich empfehle Ihnen, auf kontinuierliche Testwerkzeuge zu achten.
Was zu testen?
Offensichtlich testen Sie im Komponententest das Verhalten einer einzelnen Einheit (keine Aufrufe, da diese später geändert werden können) . Machen Sie es sich auch zur Regel, alle Fehler, die Sie gefunden haben, mit Unit-Tests abzudecken, um zu beweisen, dass sie behoben sind. Was ist mit der Codeabdeckung? Die Codeabdeckung ist kein Ziel, sondern nur eine Maßnahme, mit der Sie verstehen, welchen Teil der Logik Sie bei Komponententests vergessen haben. Es wäre ein großer Fehler, wenn Sie sich entscheiden würden, jede Codezeile mit Unit-Tests abzudecken.
Mittelspiel
Testen Sie nur eines
Verwechseln Sie Unit-Tests nicht mit Integrationstests, bei denen das Testen von mehr als einer Sache normal ist. Die Idee des Unit-Tests besteht darin, zu beweisen, dass ein separates Anwendungsmodul funktioniert oder nicht. Sie müssen leicht und sicher verstehen, welches Verhalten in Ihrem Code fehlschlägt und wie Sie es beheben können. Wie viele Asserts sollten Sie verwenden? Eins! Die Verwendung vieler Asserts kann der Codegeruch sein, dass Sie mehr als eine Sache testen. Darüber hinaus besteht die Möglichkeit, dass jemand Ihrem Test eine neue Aussage hinzufügt, anstatt eine andere zu schreiben. Und wie können Sie verstehen, wie Ihre anderen Behauptungen abgeschlossen wurden, als die erste fehlschlug?
Vermeiden Sie Logik
Fehler in Tests sind für Entwickler am schwierigsten zu finden. Die Wahrscheinlichkeit, einen Fehler in Ihrem Testcode zu bekommen, steigt, wenn Sie sich dazu entschließen, Ihrem Test Logik hinzuzufügen. Es wird schwieriger zu lesen, zu verstehen und zu pflegen. Die Verwendung von for , foreach , if , switch und anderen Operatoren in einem Test kann auch ein Codegeruch sein, den Sie mehr als eine Sache testen.
AAA
Das Anordnen, Handeln, Bestätigen ist ein häufig verwendetes Muster, mit dem Sie Ihren Testcode entsprechend in drei Phasen organisieren können. Es trennt klar, was getestet wird, von den Einrichtungs- und Überprüfungsschritten. Dies ist eine der Best Practices und macht Ihren Testcode lesbarer und wartbarer. Verwenden Sie jedoch keine AAA- Kommentare in Ihren Tests, wenn Sie Ihren Code sauber und lesbar halten möchten. Kompetent erstellter Test drückt AAA-Idee auch ohne Kommentare aus.
Halten Sie sich an die Namenskonvention
Testnamen sollten nicht nur für den Autor beschreibend und verständlich sein. Es gibt viele Testbenennungsstrategien , aber ich mag die von Roy Osherove : [MethodName_StateUnderTest_ExpectedBehavior] . Es enthält alle erforderlichen Informationen zum Test in formatierter Form. Es ist für jeden Entwickler einfach, diese Strategie zu verfolgen.
Beispiele:
public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () public void Sum_simpleValues_Calculated () public void Parse_OnEmptyString_ExceptionThrown() public void Parse_SingleToken_ReturnsEqualTokenValue ()
Beachten Sie jedoch, dass Sie möglicherweise eine Namenskonvention haben, die Sie bei Ihrem aktuellen Projekt befolgen müssen. Verwechsle sie nicht.
Vorbereitung der Testdaten
Das Erstellen von Testdaten kann Unordnung und Leid in Ihren Testcode bringen. Sie können mit dieser Situation konfrontiert werden, wenn:
- Sie müssen den Konstruktor Ihres Modells in jedem Code ändern, in dem dieses Modell erstellt wird (dies geschieht normalerweise, wenn Ihr Modell unveränderlich ist) .
- Beim Erstellen Ihrer Testdaten sind viele Code-Duplikate vorhanden.
- Sie müssen viele "magische Daten" an Ihren Modellkonstruktor übergeben (z. B.
new Device("Stub", 10, true, "http"); ) ; - Sie haben das Gefühl, dass Sie eine Art Zufallsdatengenerator erstellen müssen.
- Es ist schwierig für Sie, Testdatensammlungen zu erstellen.
Vor diesem Hintergrund müssen Sie einige gängige Alternativen in Betracht ziehen: Objektmutter und [Fließendes Builder-Muster]. Diese Ansätze sind auch gute Teamplayer, so dass Sie sie zusammen verwenden können.
Verwenden Sie keine zufälligen Daten, da Ihr Test möglicherweise auf bestimmte Werte anspricht. Infolgedessen können Sie in Ihrem Test einen bösen Heisenbug bekommen, der schwer zu finden und zu reproduzieren ist.
Lernen Sie Ihr Test-Framework kennen
Lernen Sie alle Attribute, Aussagen und anderen Funktionen Ihres Testframeworks kennen. Es hilft Ihnen, Ihre Tests lesbarer und eleganter zu gestalten. Im NUnit- Framework können Sie beispielsweise zwei Assertionsmodelle verwenden und eines auswählen, das Ihnen am besten gefällt:
Assert.AreEqual(StatusCode.OK, response.StatusCode);
oder
Assert.That(StatusCode.OK, Is.EqualTo(response.StatusCode));
Vergessen Sie nicht die Setup- und Teardown-Methoden, TestCase- und Category-Attribute sowie die Sammlungsbestätigungen. Verwechseln Sie erwartete und tatsächliche Ergebnisparameter nicht mit Aussagen.
Endspiel
Ihr Testcode hat das gleiche Privileg wie Ihr Produktionscode, den Sie schreiben und pflegen müssen. Vergessen Sie nicht die SOLID-Prinzipien. Außerdem sollten Ihre Komponententests lesbar sein, und es gibt mehrere Gründe dafür. Erstens sollte die Absicht Ihrer Tests verständlich und klar sein. Dies bedeutet, dass Sie beim Lesen Ihrer Tests keine Zeit verschwenden müssen. Zweitens sollte es einfach sein, Ihre Tests zu pflegen, Probleme zu erkennen und zu beseitigen, ohne sie zu debuggen.
Unit Testing ist eine große Philosophie, die nicht nur in einem Beitrag diskutiert werden kann. Hier erklärte ich allgemeine Ansätze und häufige Fragen im Zusammenhang mit Unit-Tests. Wenn Sie tiefer tauchen möchten, finden Sie diese Links möglicherweise interessant:
Roy Osherove Blog
Roy Osherove Buch "Die Kunst des Unit Testing"
Bleib ruhig und teste die Einheit