Automatische Tests

von Sascha Frick (September 02)

In der Okotber 2002 Ausgabe von iX macht Dierk König in seinem lesenswerten Artikel "Sklaventreiber - Automatische Akzeptanztests auf XML-Basis" folgende zutreffende Aussage: "Das Schreiben automatischer Tests kostet Zeit. Jeder, der etwas anderes behauptet, will ein Tool verkaufen".

Das scheint zunächst Wasser auf die Mühlen all derer zu sein, die automatische Tests als zu zeitaufwendig und als zu teuer ansehen und daher z.B. auf den konsequenten Einsatz von regressiven Unit-Tests verzichten. Doch König liefert schon im nächsten Satz das Gegenargument, indem er treffend fest hält: "Die gute Nachricht ist, dass man diese Zeit mehrfach wieder zurückbekommt."

Und weiter schreibt er: "Für eine einmalige Ausführung ist der manuelle Test normalerweise ökonomischer. Vielleicht auch noch bei zweimaliger Ausführung. Es kommt aber der Punkt, ab dem sich die Investition in den automatischen Test amortisiert."

Diese Einschätzung wird jeder unterschreiben können, der automatisierte Tests systematisch anwendet. Automatisches Testen erhöht die Robustheit, die Aenderungsfreundlichkeit und die Verständlichkeit einer Anwendung drastisch. Die Frage ist nur, warum dann in der Praxis das Nicht-Testen eher die Regel denn die Ausnahme darstellt. Die schiere Zahl der Veröffentlichungen zu diesem Thema müsste vermuten lassen, dass systematisch automatisiertes Testen einen festen Bestandteil im Alltag eines Software-Entwicklers bildet. Gerade Bücher wie Unit Tests mit Java zeigen z.B. anschaulich, wie sich Unit-Tests effektiv und effizient nutzen lassen. Aber auch im Netz finden sich zum Beispiel auf der Xp-Homepage unzählige Beweise für die Mächtigkeit von automatischen Tests.

Wer heute wirklich iterativ inkrementelle Entwicklung, die diesen Namen auch verdient, kontrolliert und zielgerichtet betreiben will, der kommt um das systemtaische Testen nicht herum. Wie Martin Fowler in seinem Buch zum Thema Refactoring schreibt, ist eine geordnete inkrementelle Entwicklung von Software ohne automatische Tests undenkbar. Wer etwas anderes behauptet, weiss schlicht nicht, wovon er redet.

Die Frage bleibt, warum das Testen in vielen Projekten noch immer ein Mauerblümchendasein fristet. Die Gründe dafür dürften vielfältig sein. Zum einen ist es gerade am Anfang nicht einfach und daher frustrierend, gute Tests zu schreiben und zum anderen ist der Zeitdruck in den meisten Projekten so gross, dass man auf alles verzichtet, was vordergründig nicht zur produktiven Arbeit gehört.

Und auch wenn unzählige Erfahrungsberichte, Bücher und Zeitschriften die Mächtigkeit des Testens preisen und loben, es wird alles beim alten bleiben, solange den Entwicklern die persönliche positive Erfahrung mit systematischen und automatischen Tests fehlt.

So stellt sich also die Frage, was zu tun ist, um Entwickler und Manager(!) auf breiter Front dazu zu bringen, Tests als Verbündete und nicht als Feinde zu betrachten. Die Antwort auf diese Frage möchte ich einem der nächsten Denkmal-Artikel näher beleuchten.