Komponententests: Testfälle und Isolation verstehen

Die Softwarebeispiele und Aufgaben in diesem Artikel sind fiktiv. Eine Funktion ist ein benannter Programmteil, den du mit Eingaben aufrufen kannst und der zum Beispiel ein Ergebnis zurückgibt. Stell dir eine Funktion vor, die aus einem Warenwert die Versandkosten berechnet. Du möchtest wissen, ob diese eine Berechnung richtig arbeitet – unabhängig von Benutzeroberfläche, Datenbank und Zahlungsdienst.

Was als Komponente gilt, hängt vom Projekt ab. In einem Softwareprojekt kann es eine Funktion, Methode, Klasse oder ein Modul sein. Eine Methode ist eine Funktion, die zu einer Klasse gehört. Eine Klasse beschreibt den Aufbau und das Verhalten gleichartiger Objekte; ein Modul fasst zusammengehörigen Programmcode zusammen. In einem technischen System kann eine Komponente auch Mechanik, Elektronik und Software enthalten. Vor dem Test muss deshalb klar festgelegt sein, wo die Grenze des Prüfgegenstands verläuft.

In vielen Softwarekontexten werden Unit-Test, Modultest und Komponententest ähnlich oder sogar gleichbedeutend verwendet. „Unit“ betont meist eine kleine Codeeinheit. „Komponente“ kann je nach vereinbarter Grenze weiter gefasst sein. Entscheidend ist nicht das Wort allein, sondern was isoliert geprüft wird.

Eine Schnittstelle legt fest, wie Programmteile Daten austauschen oder einander aufrufen. Die Teststufen unterscheiden sich vor allem durch Prüfgegenstand und Frage:

Ein Beispiel zeigt den Fokuswechsel:

1. Ein Komponententest prüft, ob berechneVersandkosten(49) den festgelegten Betrag liefert.
2. Ein Integrationstest prüft, ob Warenkorb und Versanddienst die Daten im richtigen Format austauschen.
3. Ein Systemtest prüft den vollständigen Bestellablauf im integrierten System.

Die Stufen ersetzen einander nicht. Ein korrekter einzelner Baustein kann über eine fehlerhafte Schnittstelle falsch eingebunden sein. Umgekehrt kann ein Systemtest einen Fehler zeigen, ohne seine Ursache so genau einzugrenzen wie ein Komponententest.

Ein Testfall beginnt bei einer Anforderung, also einer Vorgabe für das gewünschte Verhalten. Die Spezifikation hält solche Vorgaben fest. Für unser fiktives Beispiel lautet sie:

rabatt(preis, mitglied) gibt für Mitglieder 10 Prozent des nicht negativen Preises als Rabatt zurück. Für Nichtmitglieder beträgt der Rabatt 0. Negative Preise werden durch die Fehlermeldung „Preis ungültig“ abgewiesen, ohne einen Rabatt zurückzugeben.

Bei rabatt(80, wahr) heißt die Funktion rabatt. Die Werte in Klammern sind ihre Eingaben: der Preis 80 und die Mitgliedschaft. wahr bedeutet „ist Mitglied“, falsch bedeutet „ist kein Mitglied“. Preise und Rabatte verwenden dieselbe Geldeinheit; eine konkrete Programmiersprache brauchst du für das Beispiel nicht.

Gehe in drei Schritten vor:

1. Ausgangszustand und Eingaben festlegen: Welche Werte und Voraussetzungen gelten?
2. Operation ausführen: Welche Komponente wird aufgerufen?
3. Soll und Ist vergleichen: Welches beobachtbare Ergebnis fordert die Spezifikation?

Ein einzelner Normalfall reicht nicht. Wähle Testfälle mit unterschiedlichen Aufgaben:

• Normalfall: ein typischer gültiger Wert, etwa 80 und Mitglied.
• Randfall: ein Wert an einer bedeutsamen Grenze, hier 0 und Mitglied; erwartet wird 0.
• Alternative gültige Bedingung: 80 und kein Mitglied; erwartet wird 0.
• Ungültiger Fall: ein negativer Preis; erwartet wird die in der Spezifikation festgelegte Abweisung.

Viele Komponenten rufen andere Teile auf: eine Datenbank, einen Dienst, eine Uhr oder eine Hardware-Schnittstelle. Würdest du alle echten Abhängigkeiten einbinden, könnte ein Fehler außerhalb des Prüfgegenstands den Test beeinflussen. Dann wäre die Ursache schwerer zu erkennen.

Eine Abhängigkeit ist hier ein anderer Teil, den die Komponente benötigt. Für einen isolierten Komponententest ersetzt du solche Teile bei Bedarf durch Testdoubles, also eigens für den Test eingesetzte Ersatzobjekte. Sie liefern kontrollierte Antworten oder zeichnen Aufrufe auf.

Ein Testdouble ist selbst nur ein Modell. Bildet es Antwortcodes, Plausibilitätsprüfungen oder Zustände unvollständig ab, kann der Test trotz eines späteren Integrationsfehlers grün sein. Außerdem können Test und Implementierung denselben falschen Denkfehler enthalten.

Ein fehlgeschlagener Test zeigt zunächst eine Abweichung zwischen Soll und Ist. Er sagt noch nicht automatisch, welche Codezeile die Ursache ist.

Gehe systematisch vor:

1. Prüfe, ob Anforderung, Eingaben und Sollwert eindeutig sind.
2. Stelle sicher, dass der Testaufbau nicht selbst fehlerhaft ist.
3. Verfolge die Verarbeitung bis zur ersten falschen Zustandsänderung oder Ausgabe.
4. Behebe die ermittelte Ursache, je nach Befund in der Komponente oder im Testaufbau.
5. Führe den fehlgeschlagenen Test und die übrigen passenden Tests erneut aus.
6. Bewahre passende Tests auf und führe sie bei späteren Änderungen wieder aus.

Ein Wiederholungstest nach Fehlerbehebung prüft, ob die konkrete Korrektur wirkt. Regressionstests suchen nach unbeabsichtigten Verschlechterungen durch eine Änderung. Dazu gehört sowohl das erneute Auftreten eines bekannten Fehlers als auch die Beschädigung anderer zuvor funktionierender Abläufe.

Auch Testcode ist Code. Er kann falsche Erwartungen, ungeeignete Daten oder problematische gemeinsame Zustände enthalten und sollte deshalb nachvollziehbar benannt, gepflegt und überprüft werden.