Version vom 1. August 2021, 12:48 Uhr

Tutorial: 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:

Umrechnen von Temperatur-Werte von Celsius nach Fahrenheit

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 Enwickler lust, nach der Impllementierung noch irgendetwas zu tun.

Vor allem aber hat das Programm die Tendenz sich so zu entwickeln, daß es sich gar nicht richtig testen läßt.

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.

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.
Wichtig dabei ist:

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.