Open Source im professionellen Einsatz
Linux-Magazin 11/2005

Perls Werkzeugkasten für Regressionstests

Kontrolle ist besser

Eine Testsuite hilft Fehler zu korrigieren und Teile des Systems umzuschreiben, ohne die bestehende Codebasis dabei zu ruinieren. Die unbestechlichen Kontrolleure heißen etwa Test::More oder Test::Deep.

672

Auch bei der Weiterentwicklung und beim Refactoring stellt sich die Frage: Ist garantiert, dass ein Bugfix keine unerwünschten Nebenwirkungen hat? Wer ohne Aufwand ein paar hundert Tests ablaufen lassen kann, tauscht mit weniger Herzklopfen Teile des Systems aus und schläft ruhiger. Deshalb kommen selbst jene an einer Suite für Regressionstests nicht vorbei, die Bewegungen wie Extreme Programming für neumodischen Firlefanz halten.

Wenn ein Programm auf Anhieb funktioniert, macht es sich allein schon dadurch verdächtig - der Fall ist zu selten. Testgetriebene Entwicklung, die sich als Methode des Extreme Programming etabliert hat, baut gerade auf jenen unvermeidlichen Fehlern auf, die ständig erweiterte Testläufe finden. Ein Testfall geht schief, der Programmierer behebt das Problem - und prompt funktioniert das neu implementierte Feature.

Das motiviert nicht nur während der Entwicklung, jeder neue Test vergrößert auch die Suite, als deren Bestandteil er später wieder und wieder abläuft. So summieren sich kleine Schritte zu einem Gesamtwerk, das im Nachhinein keine Qualitätssicherungs-Abteilung der Welt zustande brächte.

Suite ist Standard

In der Perl-Community gehört es glücklicherweise zum guten Ton, einem CPAN-Modul eine Testsuite beizulegen, die alle wichtigen Funktionen überprüft. Wenn aber kein Modul, sondern nur ein kleines Skript entsteht? Über die Jahre habe ich festgestellt, dass ein Skript nur Kommandozeilenparameter verarbeiten sollte, die Hilfetexte ausspucken, und für alles Weitere Module verwenden, in die es alle anderen Funktionen packt. Von diesen Modulen profitieren später eventuell auch andere Skripte. Und selbstverständlich liegen ja jedem Modul eine Dokumentation und eine lückenlose Testsuite bei, oder etwa nicht?

Das TAP-Protokoll (Test Anything Protocol) hat sich in der Perl-Welt für Regressionstests durchgesetzt. Es gibt in der Regel zuerst eine Kopfzeile aus, die die Anzahl der folgenden Tests enthält. Darauf folgt je eine Zeile für jeden Testfall, die im Erfolgsfall »ok« und im Fehlerfall »not ok« lautet:

1..3
ok 1
not ok 2
ok 3


Bei Hunderten von Testfällen wäre die Ausgabe natürlich schwer zu überblicken. Darum kümmert sich eine darüber liegende Schicht um eine Zusammenfassung. In wenigen Zeilen spuckt sie aus, ob alles glatt ging oder wie viele Testfälle versagten. Da alle Testfälle ähnliche Zusammenhänge prüfen und Aktionen einleiten, gibt es spezielle Testmodule wie Test::More, die redundanten Code vermeiden helfen.

Auf Herz und Nieren

Traditionell haben Perl-Testskripte die Endung »*.t« und liegen im Verzeichnis »t« einer Modul-Distribution. Das Beispielskript »simple.t« (siehe Listing 1) testet das Modul Config::Patch vom CPAN, das Konfigurationsdateien flickt. Zuerst legt »Test::More« mit der Anweisung »tests => 4« fest, dass genau vier Testfälle ablaufen sollen. Das ist wichtig, denn falls die Testsuite unerwartet abbricht, sollte sie dies melden.

Weil die Test­suite gelegentlich schnell wächst, weichen manche Entwickler diese Prüfung mit »use Test::More qw(no_plan);« temporär auf, aber letztlich ist eine fest vorgegebene Testanzahl doch der bessere Weg.

Tabelle 1:
Test-Utilities

 

Modul

Funktion

Test::Simple

Gebräuchlichstes Testutility, enthält Test::More

Test::Deep

Vergleicht tief verschachtelte Strukturen

Test::Pod

Validiert POD-Dokumentation

Test::Pod::Coverage

Prüft, ob alle Funktionen dokumentiert sind

Test::NoWarnings

Schlägt bei Warnungen an

Test::Exception

Prüft, ob das Programm Exceptions erzeugt

Test::Warn

Prüft, ob Programm Warnungen richtig absetzt

Test::Differences

Grafische Darstellung von Unterschieden

Test::LongString

Prüft lange Strings

Test::Output

Fängt Ausgaben nach STDERR/STDOUT ab

Test::Output::Tie

Fängt Ausgaben an Filehandles ab

Test::DatabaseRow

Prüft Ergebnisse von Datenbankabfragen

Test::MockModule

Zusätzliche Module simulieren

Test::MockObject

Zusätzliche Objekte simulieren

Das Testskript »simple.t« prüft mit »use_ok()« (aus Test::More) zunächst, ob sich das Modul überhaupt laden lässt. Der Konstruktor »new« gibt (hoffentlich) ein Objekt zurück. Die daraufhin aufgerufene Funktion »ok()« aus Test::More schreibt »ok 2« auf die Standardausgabe, falls das Objekt einen wahren Wert hat, und »not ok 2«, falls nicht. Ein optional an »ok()« übergebener dritter Parameter setzt einen Kommentar, damit klar wird, welcher Testfall gerade abläuft. Abbildung 1 zeigt die Ausgabe des Skripts.

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Datumsarithmetik

    Gehirnakrobaten rechnen gerne vor Publikum, auf welchen Wochentag ein zugerufenes Datum fällt. Den Trick kann auch Otto Normalrechner mit etwas Übung lernen. Ob er zuverlässig funktioniert, prüft das im Snapshot vorgestellte Skript mit aktueller Perl-Technologie.

  • Browser ferngesteuert

    Das Testen komplexer Webapplikationen erfordert nicht unbedingt teure proprietäre Tools wie Test Director oder Silk Performer: Selenium gibt's umsonst. Es steuert alle gängigen Browser unter verschiedenen Betriebssystemen fern und lässt sich unter anderem mit Perl programmieren.

  • Perl-Snapshot

    Ob die Linux-Installation nach einem Update noch wie gewünscht funktioniert, findet der sorgfältige Admin nicht erst im Laufe der Zeit heraus, sondern mittels einer Testsuite vor dem Ausrollen.

  • Perl-Snapshot

    Test-driven Development mit einer nebenbei generierten Testsuite verspricht Code mit weniger Fehlern. Michael "Perlmeister" Schilli betritt gleich den Pfad der Agilität und findet am Wegesrand zufällig ein passendes, nagelneues CPAN-Modul.

  • Perl-Snapshot

    Mit dem Test-Framework Cucumber – englisch-botanisch für Gurke – formulieren Entwickler und Produktabteilung gemeinsam Testfälle, und zwar nicht als Programmcode, sondern in leserlichem Englisch oder Deutsch. Dem anfänglich skeptischen Perlmeister schmeckt's.

comments powered by Disqus

Ausgabe 09/2017

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.