Komponententests: Testfälle und Isolation verstehen

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. 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.

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, nicht bei einem zufällig gewählten Eingabewert. Angenommen, die Spezifikation lautet:

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 abgewiesen.

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.

Für einen isolierten Komponententest ersetzt du benötigte Abhängigkeiten deshalb bei Bedarf durch Testdoubles. 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 Ursache in der Komponente.
5. Führe den fehlgeschlagenen Test und die übrigen passenden Tests erneut aus.
6. Bewahre den Test als Regressionstest auf, wenn er einen behobenen Fehler dauerhaft abdecken soll.

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.