Tests make things better

... und Perl ist mittendrin!

Wer kennt sie nicht - die berühmt berüchtigten Bluescreens oder andere Fehlermeldungen? So ziemlich jeder dürfte schonmal vor dem Computer gehockt und eben diesen verflucht haben. Warum passiert so etwas? Und warum ausgerechnet dann wenn ich es überhaupt nicht gebrauchen kann? Wir sollten unseren Kunden und uns selbst so etwas nicht zumuten. Ein einfaches - aber auch ungeliebtes - Mittel sind Tests. Die Tests können zwar keine 100%ige Sicherheit auf Fehlerfreiheit geben, aber sie erhöhen die Wahrscheinlichkeit, dass das Programm richtig funktioniert.

Bei den Modulen zum Testen von Modulen und der Dokumentation wird auf jede einzelne Methode eingegangen, da diese Methoden in Testskripten sehr häufig verwendet werden. Bei den Modulen zum Testen von Web-Applikationen und Konsolen-Programmen wird nur eine allgemeine Erläuterung gegeben.

In diesem Artikel werden einige Module aus dem Test::*-Namespace vorgestellt und es wird zum Schluss an Hand einer beispielhaften Modulentwicklung gezeigt, wie man von Anfang an mit Tests umgeht. Bevor es aber losgeht, werden noch ein paar allgemeine Dinge zu Tests genannt.

Warum Tests?

Tests haben einen "schlechten Ruf", weil es kein produktiver Code ist. Was aber häufig nicht gesehen wird, ist die Tatsache, das Tests den produktiv-Code noch produktiver macht. Kaum ein Entwickler schreibt gerne Tests, aber wenn man klein anfängt, ist das alles gar nicht mehr so schlimm.

"Ich brauche keine Tests!"

... waren vielleicht die letzten Worte des Ingenieurs, der die Software für die Ariane 5-Rakete einsetzte. 1996 stürzte eine unbenannte Ariane-5 Rakete ab, weil veraltete Software eingesetzt wurde, die noch aus Ariane 4-Zeiten stammte und nicht an die Ariane 5-Begebenheiten angepasst wurden.

Viele "herrliche" Bugs und ihre Auswirkungen sind unter http://www5.informatik.tu-muenchen.de/~huckle/bugs.html zu finden. Diese Beispiele zeigen, dass Tests nicht nur "Schönheitsfehler" finden, sondern auch erhebliche Kosten einsparen können.

Programmierer sind Menschen und Menschen machen Fehler. Das ist ja auch (meistens) nicht schlimm, aber man sollte doch versuchen, die Auswirkungen zu begrenzen. Diese Fehler sollten auch nicht unbedingt zu Kunden gelangen.

"Ich weiß was mein Skript macht"

Das will auch niemand anzweifeln. Doch manchmal kommt der Chef am Freitag nachmittag rein und möchte noch etwas am Programm geändert haben - bis zum Wochenende. Da kommt Hektik und Unruhe auf. "Da muss ich nur an dieser Stelle etwas ändern ...". Sicher, dass es nur diese eine Stelle war? In der Hektik oder wenn man sein Skript mal zwei, drei Monate aus den Augen gelassen hat, übersieht man doch mal was.

Wenn man nach einer Änderung die Tests laufen lässt, kann man gleich sehen, ob man nicht doch aus Versehen einen neuen Bug eingebaut hat.

Test-driven Development

Es gibt in der Softwareentwicklung auch den Ansatz, dass die Tests vor dem eigentlichen Code existieren. Wie später gezeigt wird (im Abschnitt Test::More), bietet auch Perl eine geeignete Möglichkeit, dies umzusetzen.

-- ReneeBaecker - 15 Apr 2009