Warum Softwaretests konkrete Fehlerfälle brauchen
Tests sollen beweisen, dass etwas funktioniert. Tatsächlich beweist ein Test nur, dass er durchläuft — und das ist nicht dasselbe. Dieser Text erklärt den Unterschied und was daraus folgt.
Das lernen Sie
Ein grüner Test beweist nur sich selbst
Ein Test ist ein kleines Programm, das ein anderes Programm aufruft und das Ergebnis mit einer Erwartung vergleicht. Läuft er durch, heißt das: In diesem einen Fall kam heraus, was der Test erwartet hat.
Daraus folgt eine unangenehme Möglichkeit: Ein Test kann grün sein, weil er nichts prüft. Er ruft etwas auf, erwartet nichts Konkretes, und bleibt auch dann grün, wenn die geprüfte Stelle gar nicht mehr existiert.
// Beweist nichts: prueft nur, dass nichts geworfen wurde
public function testBerechnung(): void
{
$ergebnis = $this->rechner->brutto(1000);
self::assertNotNull($ergebnis);
}
// Beweist etwas: nennt Eingabe und erwartetes Ergebnis
public function testBruttoMitRegelsatz(): void
{
self::assertSame(1190, $this->rechner->brutto(1000));
}
// Beweist den Fehlerfall: hier liegt der eigentliche Wert
public function testNegativerBetragWirdAbgewiesen(): void
{
$this->expectException(InvalidArgumentException::class);
$this->rechner->brutto(-1);
}Die Gegenprobe gehört dazu
Ein neuer Test für einen gefundenen Fehler ist nur dann einer, wenn er OHNE die Korrektur durchfällt. Klingt selbstverständlich, wird aber regelmäßig übersprungen — und dann hat man einen Test, der den Fehler nicht bemerkt hätte.
Wir machen das deshalb ausdrücklich: Korrektur zurücknehmen, Test laufen lassen, rot sehen, Korrektur wieder einsetzen, grün sehen. Erst dann zählt er. Dasselbe gilt für Tests mit Platzhaltern: Wenn der Platzhalter das Ergebnis vorgibt, das geprüft werden soll, prüft der Test den Platzhalter.
Welche Fälle sich lohnen
Was sich selten lohnt: Tests für Code ohne Entscheidung, etwa reines Durchreichen von Werten. Dort kostet der Test Pflege und findet nichts.
Ein Beispiel aus der Praxis
Was eine Abdeckungszahl nicht sagt
„85 Prozent Testabdeckung" bedeutet: 85 Prozent der Codezeilen wurden während der Tests einmal ausgeführt. Es bedeutet nicht, dass ihr Verhalten geprüft wurde. Eine Reihe von Tests ohne echte Erwartungen erzeugt hohe Abdeckung und findet nichts.
Die bessere Frage an ein Projekt lautet deshalb nicht „wie hoch ist die Abdeckung", sondern: Gibt es für die drei Regeln, die im Betrieb am meisten weh täten, je einen Test mit Eingabe und erwartetem Ergebnis — und fallen diese Tests durch, wenn man die Regel absichtlich kaputt macht?
Häufige Missverständnisse
Über den Autor
Fabian Lücker ist geschäftsführender Gesellschafter der PHP-Schmiede KG in Rheine und seit 2007 in der Softwareentwicklung tätig. Er verantwortet Entwicklung und Konzeption und schreibt hier über Entscheidungen, die in echten Projekten anfallen.