Die 5 Richtlinien für Unit-Tests

Leitlinie №2.) Vermeiden Sie if-Anweisungen in einem Test

Eine if-Anweisung in einem Test bedeutet, dass der Test je nach Situation verschiedene Dinge tun soll. Wenn-Anweisungen müssen getestet werden. Wie werden Sie den Test testen? Und werden Sie den Test testen, der den Test testet? Wo wird er enden?

Aus der Sicht der Anforderungen funktioniert etwas entweder oder es funktioniert nicht. Das ist statisch. Das Ergebnis eines Tests wird weniger vertrauenswürdig, wenn der Test dynamisch ist. Und Tests werden dynamisch, wenn sie je nach Situation unterschiedliche Dinge tun.

Leitfaden №3.) Unit-Tests testen nur "new()" die zu testende Einheit.

Unit-Tests sind klein. Der Testumfang eines Unit-Tests ist auf eine einzige Methode oder Klasse beschränkt. Aus dieser Perspektive wäre es sinnvoll, das Schlüsselwort "new ()" nur für die Instanziierung der Klasse zu verwenden, die die zu testende Methode enthält.

Wenn Sie verschiedene Klassen kombinieren, verschiedene Eingaben durch sie laufen lassen und das Ergebnis überprüfen, wird der Test weniger zielgerichtet. Welche Klasse muss repariert werden, wenn der Test fehlschlägt? Beispiel:

 

Vermeiden Sie diese! Welche Klasse muss repariert werden, wenn der Test fehlschlägt? Kalender oder Zeitplan?

Instanzieren Sie nicht die Abhängigkeiten der Klasse, die Sie testen, mit dem Schlüsselwort "new ()". Verwenden Sie Frameworks wie Moq oder NSubstitute, um Mocks und Stubs zu erstellen, die sie ersetzen. Auf diese Weise sind die Tests zielgerichteter und liefern ein besseres Feedback:

 

In Ihrem Unit-Test instanziieren Sie nur die zu testende Einheit (Kalender). Der Fehler muss sich in der Klasse Calendar befinden.  

Leitlinie №4.) Unit-Tests enthalten keine fest kodierten Werte, es sei denn, sie haben eine bestimmte Bedeutung

Unit-Tests sollen beschreibend sein: Wenn der Code bei einer bestimmten Eingabe ausgeführt wird, muss das Ergebnis etwas sein.

Kodieren Sie die Testdaten nicht fest. Das macht es schwieriger, den Test zu verstehen. Angenommen, der folgende Test schlägt fehl. Würden Sie wissen, wo das Problem liegt? Sie werden debuggen müssen, um herauszufinden, was falsch ist:

 

Vermeiden Sie diese: Wenn ein solcher Test fehlschlägt, ist es schwer herauszufinden, was falsch ist.

Wenn Fixtures mit einem Framework generiert werden, wird der Test viel klarer. Wenn der folgende Test fehlschlägt, bedeutet dies, dass ein Code zur Validierung einer Telefonnummer geändert wurde. Sie müssen nicht debuggen, um das herauszufinden:

 

Definieren Sie nur die Eigenschaften, die die Logik auslösen, die Sie testen wollen. In diesem Fall, , sollte es offensichtlich sein, dass etwas bei der Validierung einer Telefonnummer nicht funktioniert, wenn dieser Test fehlschlägt.

Leitfaden №5.) Unit Tests sind zustandslos

Nichts ist schlimmer als bestandene Tests und eine fehlerhafte Anwendung in der Produktion. Zustandsbezogene Tests können falsch-positive Ergebnisse liefern. Nehmen wir das folgende Beispiel:

 

Vermeiden Sie diese: Zustandsbezogene Unit-Tests machen das Ergebnis des Tests fragwürdig.

Angenommen, der Test GivenAppointment_ThenErrorOccurs wird zuerst ausgeführt, dann erzeugt der Test GivenAppointmentThenAppointmentAppearsInList entweder einen falsch positiven oder einen falsch negativen Wert.

Entwickeln Sie Unit-Tests so, dass sie vertrauenswürdig sind. Entwickeln Sie sie so, dass sie unabhängig von der Reihenfolge ihrer Ausführung erfolgreich sind. Das Ergebnis der Tests muss immer gleich sein, egal wie oft sie ausgeführt werden.