Aktuelle Version vom 30. August 2021, 10:17 Uhr

Unit-Tests schreiben

Das Schreiben von Unit-Tests ist eine einfache Sache, es lohnt sich aber das an kleinen Beispielen zu üben bis es locker aus dem Handgelenk kommt. Unit-Tests haben viele Aspekte und Facetten, wir fangen mal mit dem einfachsten Fall an: Testen einer einzelnen Funktion/Methode.

Funktion für das Tutorial wählen

Für das Tutorial wähle zunächst eine einfache Funktion. Sie sollte überschaubar sein, aber eine Reihe unterschiedlicher Varianten haben die sich zu testen lohnen. Als Beispiel nehmen wir hier die Berechnung des arithmetischen Mittels (aka der Durchschnitt) einer Reihe von Zahlen.

Um es einfacher zu machen, sind für die Eingabe nur ganze Zahlen erlaubt. Das Ergebnis ist in der Regel keine ganze Zahl mehr.

Die zu implementierende Methode habe die Signatur

float schnitt(int[] zahlen);

oder

float schnitt(int... zahlen);

Funktion implementieren

Schreibe nun eine Klasse mit einer Methode die die Funktion berechnet.

Normalerweise schreibt man Unit-Tests während man die Funktionalität entwickelt. Da für dieses Tutorial die Unit-Tests im Fokus stehen, ignorieren wir das mal. Die Implementierung darf also bereits erfolgt sein.

Unit-Tests schreiben

Lege nun eine Unit-Test-Klasse an und schreibe Tests dazu. Lies dazu die Abschnitte "Regeln..." und "Aufbau..." in Gestaltung von Unit-Test

Frage Dich dabei

Was sollen die Tests erreichen?
Was muß getestet werden, welche Tests benötige ich?
Wieviele Test sind nötig, wann habe ich genug getestet?
Woher bekomme ich Testdaten, was ist dabei wichtig?

Das wirkliche Leben

Unit-Tests nach Abschluß der Implementierung zu schreiben ist nicht empfehlenswert. Zunächst einmal hat dazu (fast) kein Entwickler Lust, sich nach der Implementierung noch mit einem Code zu beschäftigen.

Vor allem aber hat ein Programm ohne Unit-Tests die Tendenz sich so zu entwickeln, daß es sich gar nicht richtig testen läßt. Unser Beispiel ist ist einfach und überschaubar. "Echte" Software wird im Laufe der Zeit erweitert und angepaßt. Oft genug wird der Code dann irgendwo reingehackt; die entstehenden Methoden werden sehr schnell sehr komplex und sind dann nicht mehr richtig zu testen.

Deshalb ist es empfehlenswert, Unit-Tests während der Entwicklung zu schreiben. Das ist auch die Voraussetzung für modernere Programmiertechniken wie agile Entwicklung und TDD. Ein paar Anmerkungen dazu finden sich hier.

@@ Zeile 2: / Zeile 2: @@
 [[Category:Ausbildung]]
 __NOTOC__
-= Tutorial: Unit-Tests schreiben =
+= Unit-Tests schreiben =
 Das Schreiben von Unit-Tests ist eine einfache Sache, es lohnt sich aber das an kleinen Beispielen zu üben bis es locker aus dem Handgelenk kommt. Unit-Tests haben viele Aspekte und Facetten, wir fangen mal mit dem einfachsten Fall an: Testen einer einzelnen Funktion/Methode.
@@ Zeile 34: / Zeile 34: @@
 = Das wirkliche Leben =
 Unit-Tests nach Abschluß der Implementierung zu schreiben ist nicht empfehlenswert.
-Zunächst einmal hat dazu (fast) kein Enwickler lust, nach der Impllementierung noch
+Zunächst einmal hat dazu (fast) kein Entwickler Lust, sich nach der Implementierung noch
-irgendetwas zu tun.
+mit einem Code zu beschäftigen.
-Vor allem aber hat das Programm die Tendenz sich so zu entwickeln,
+Vor allem aber hat ein Programm ohne Unit-Tests die Tendenz sich so zu entwickeln,
-daß es sich gar nicht richtig testen läßt.
+daß es sich gar nicht richtig testen läßt. Unser Beispiel ist ist einfach und überschaubar. "Echte" Software wird im Laufe der Zeit erweitert und angepaßt. Oft genug wird der Code dann irgendwo reingehackt; die entstehenden Methoden werden sehr schnell sehr komplex und sind dann nicht mehr richtig zu testen.
-Deshalb ist es empfehlenswert, Unit-Tests während der Entwicklung zu schreiben.
+Deshalb ist es empfehlenswert, Unit-Tests ''während'' der Entwicklung zu schreiben.
 Das ist auch die Voraussetzung für modernere Programmiertechniken wie agile Entwicklung und TDD.
+Ein paar Anmerkungen dazu finden sich [[Testgetriebene Entwicklung|hier]].
-== Test First Development ==
-Dieses Vorgehen hat zwei Schritte:
-# Schreibe einen Test der die Funktionalität testet und fehlschlägt (Test ist "rot")
-# Implementiere die Funktionalität bis der Test durchläuft (Test ist "grün")
-Die Herausforderung besteht -- zumindest am Anfang -- darin, Probleme so in einzelne Funktionalitäten
-zu schneiden, daß sie sich in einfachen Unit-Tests testen lassen. Das Schreiben der Tests ist eine
-Fähigkeit die man sich durch Üben recht schnell aneignen kann.
-Dieses Vorgehens hat zwei Vorteile :
-* Am Ende der Implementierung ist der Code  mit Tests vollständig abgedeckt und dokumentiert
-* Der Code kann bei Erweiterung mit Unit-Tests abgesichert werden
-== Test Driven Development (TDD) ==
-Durch Hinzufügen eines weiteren Schritts kann man das Verfahren zum TDD ausweiten
-wie Kent Beck es im Rahmen des "extreme Programming" beschrieben hat (citation?).
-Gerät durch das sture Hinzufügen einzelner Features der Blick auf das Gesamtprogramm aus dem Fokus,
-wird das Endergebnis als ein Haufen zusammengeworfener Methoden und Klassen dastehen.
-Zwar garantieren die Tests, daß das Programm tut was es soll, aber der arme Mensch der das später erweitern soll
-wird keine Freude daran haben.
-Halte nach jedem Schritt (bzw. nach jedem grün gewordenen Test)  inne und sieh Dir das Gesamtprodukt an.
-Überlege Dir:
-*Kann ich etwas besser machen?
-*Kann ich etwas zusammenfassen?
-*Kann ich etwas verallgemeinern?
-Setze Maßnahmen, die Dir sinnvoll scheinen um und überprüfe das Ergebnis anhand der Unit-Tests.<br>
-Wichtig dabei ist:
-{{quotation|Die Änderungen dürfen keine Änderungen an der bestehende Funktionalität mit sich bringen}}
-Dieses Vorgehen –- man nennt es Refactoring –- erfordert Übung und Erfahrung.
-Zögere nicht, Kollegen hinzuzuziehen, wenn Du damit Schwierigkeiten hast oder Anregungen brauchst.