Komponententests: Testfälle und Isolation verstehen

Ein Programm besteht aus vielen Teilen. Solche Teile sind zum Beispiel Klassen oder Unterprogramme. Man prüft sie in Stufen.

Der Komponententest prüft einzelne, abgrenzbare Teile der Software. Er heißt auch Modultest oder Unittest (englisch „unit“ heißt „Einheit“). Diese Tests führt häufig der Software-Entwickler selbst durch. Sie sollen zeigen, dass ein Teil technisch läuft und korrekte Teilergebnisse liefert.

Der Integrationstest prüft die Zusammenarbeit voneinander abhängiger Komponenten. Sein Schwerpunkt liegt auf den Schnittstellen. Das sind die Stellen, an denen Teile Daten austauschen.

Der Systemtest prüft das gesamte System gegen die gesamten Anforderungen. Er findet gewöhnlich auf einer Testumgebung statt. Die soll der Umgebung des Kunden möglichst ähnlich sein.

Die Stufen sind in der Praxis oft nicht scharf voneinander getrennt.

Du kannst nicht jede mögliche Eingabe testen. Darum sortierst du die Eingaben in Gruppen. Eine Gruppe heißt Äquivalenzklasse. Man erwartet, dass sich alle Werte einer Klasse gleichartig verhalten. Deshalb nimmt man an, dass jeder Wert der Klasse die gleichen Fehler findet wie jeder andere. Ziel ist, mit wenigen Testfällen möglichst viele Fehler zu finden.

Es gibt gültige und ungültige Äquivalenzklassen. Gültige Klassen enthalten gültige Eingaben, ungültige Klassen enthalten ungültige Eingaben. Tests mit gültigen Eingaben heißen Positivtests, Tests mit ungültigen Eingaben heißen Negativtests.

So gehst du vor: Zuerst schaust du, welche Eingaben erlaubt sind. Dann bildest du die Klassen. Dann wählst du für jede Klasse einen Wert aus. Zu jedem Testfall gehören die Eingabe und das erwartete Ergebnis. Das erwartete Ergebnis heißt Soll-Ergebnis. Besonders interessant sind die Grenzwerte, denn dort erwartet man ein anderes Verhalten.

Ein Komponententest prüft einen Teil isoliert, also weitgehend ohne Zusammenarbeit mit anderen Teilen. Andere Teile wie eine Datenbank, Dateien oder Unterprogramme werden deshalb oft durch Hilfsobjekte nachgebildet.

Ein Mock-Objekt (auch Attrappe) ist so ein Platzhalter für echte Objekte. Es liefert keine Echtdaten, sondern vorher zum Testfall passend festgelegte Werte. Ein Stub liefert unabhängig von der Eingabe immer die gleiche Ausgabe.

Man nimmt Mock-Objekte zum Beispiel, wenn das echte Objekt bei jedem Aufruf andere Ergebnisse liefert (etwa die aktuelle Uhrzeit), langsam oder sehr komplex ist, noch nicht existiert oder Prozesse anstößt, die man schwer rückgängig machen kann (etwa Dateien löschen).

Trotzdem können Fehler unentdeckt bleiben. Haben Testobjekt und Hilfsobjekt dieselbe falsche Annahme, merkt der Test nichts. Auch wenn der Autor der Tests zugleich der Autor des Programmteils ist, können Denkfehler im Test wieder auftauchen. Ein Test, der „grün“ ist, beweist deshalb nicht, dass der Teil fehlerfrei ist. Vollständige Tests mit den echten Teilen folgen später in Integrations- und Systemtests.

Jeder Komponententest hat meist denselben Aufbau. Erst stellst du einen Ausgangszustand her. Dann führst du die zu testende Operation aus. Zuletzt vergleichst du das Ist-Ergebnis mit dem Soll-Ergebnis. Das Ist-Ergebnis ist das, was das Programm wirklich liefert. Das Soll-Ergebnis ist der Sollwert, der aus der Spezifikation abgeleitet wird. Die Spezifikation beschreibt genau, was der Teil leisten soll.

Stimmen beide überein, lautet das Testergebnis „ok“. Weichen sie ab, liegt eine Abweichung vor, zum Beispiel ein Fehler. Sie wird bearbeitet und führt in der Regel nach der Klärung zu Testwiederholungen.

Ein Regressionstest ist die Wiederholung von Testfällen. Er soll sicherstellen, dass Änderungen in bereits getesteten Teilen keine neuen Fehler („Regressionen“) verursachen. Solche Änderungen entstehen regelmäßig bei der Pflege, Änderung und Korrektur von Software. Weil man oft wiederholt, ist es sinnvoll, die Tests zu automatisieren. Wird ein gefundener Fehler mit einem Test abgesichert, wird verhindert, dass er erneut auftritt.

Werden Tests nur unverändert wiederholt, decken sie keine neuen Fehlerwirkungen mehr auf. Darum soll man die Testfälle regelmäßig prüfen und ergänzen.