LU03a - Unit Tests

Unit Tests resp. Komponententests sind automatisierte Tests kleiner Codeeinheiten, die isoliert getestet werden und weisen Aspekte von White-Box und Black-Box Tests auf (siehe Theorie über Testverfahren). Im Wesentlichen ist ein Unit Test ein Programm, das die öffentlichen Methoden einer Klasse aufruft und überprüft, ob die Ergebnisse den Erwartungen entspricht.

Vorteile von Unit Tests

Wenn Sie Ihre Komponententests richtig geschrieben haben, bringen sie mehrere Vorteile bezgl. der Wartung des Codes:

Unit Tests bilden die Basis der Testpyramide

Wie sind Unit Tests zu implementieren?

So wie es die SOLID Principles für die Programmierung im Allgemeinen haben, gibt es auch Prinzipien für allgemeine bewährte Verfahren beim Unit Testing: die FIRST Principles. Gehen wir sie durch.

[F]ast

Sie sollten nicht zögern, die Testsuite zu jedem Zeitpunkt des Entwicklungszyklus auszuführen, selbst wenn es Tausende von Unit Tests gibt. Sie sollten in Sekundenschnelle ausgeführt werden. Wenn die Ausführung eines Tests zu lange dauert, leistet dieser wahrscheinlich mehr, als er sollte – und ist daher kein Unit Test!

[I]ndependent resp. [I]solated

Jeder einzelne Test sollte unabhängig von allen anderen sein, damit seine Ergebnisse nicht von anderen Faktoren beeinflusst werden. Mit dieser Definition sollten Sie normalerweise den „3 A’s des Testens“ folgen: Arrange, Act, Assert (auch bekannt als „Given-When-Then“).

[R]epeatable

Tests sollten wiederholbar und deterministisch sein: d.h. das Ergebnis ist jedes Mal dasselbe und zwar unabhängig von der Umgebung.

[S]self-Validating

Der Test selbst sollte Ihnen sagen, ob er bestanden wurde. Eine manuelle Überprüfung der Werte sollte nicht erforderlich sein. Die meisten Bibliotheken (wie pytest, siehe Doku) arbeiten zugunsten dieses Prinzips.

[T]horough

Ihr Test sollte alle „glücklichen Pfade“ einer Methode abdecken, alle Randfälle (bei denen Sie glauben, dass der Test fehlschlagen könnte), illegale Argumente, Sicherheitslücken, grosse Wert etc. Mit anderen Worten: jedes mögliche Szenario sollte getestet werden und nicht nur genug, um eine (nahezu) 100%ige Codeabdeckung zu haben.

Das zusätzliche T: Timely

Gemäss TDD sollten Komponententests vor dem zu testenden Produktionscode geschrieben werden. Dies geschieht, indem die Abstraktion (Schnittstelle) und dann der Test allein auf der Grundlage der Methodensignatur und -spezifikation geschrieben wird. Nachdem der Test geschrieben ist, kann der produktive Code implementiert und direkt getestet werden.


Credits: Der Inhalt dieses Artikels wurde grösstenteils direkt aus dem Englischen übernommen und nur leicht modifiziert. Das Original stammt aus diesem Beitrag der DEV Community, verfasst von Lucas Fonseca Mundim