Aufwand automatisierter Tests

Die Spatzen pfeifen es schon seit langem von den Dächern: testgetriebene Entwicklung und automatische Tests sind „in“. Wer es nicht tut, gehört zum alten Eisenoder zum Großteil der wirtschaftlich denkenden Realität.

In den letzten 10 Jahren habe ich ca. zwei Dutzend Softwareprojekte begleitet. Dabei bin ich den unterschiedlichsten Sichtweisen zum Thema „Testen“ begegnet:

• Testen ist selbstverständlich – und sollte vom Programmierer selbst durchgeführt werden.
• Der Kunde testet selbst. Ihm ist Zugang zum Bug-Tracking-System zu gewähren.
• Wir haben ein paar ausländische Praktikanten, die hätten Zeit zum Testen.
• Automatische Tests zu programmieren kostet viel Zeit, das zahlt keiner.
• Test Code ist meist länger als der eigentliche Code. Das lohnt sich nicht.
• Tests machen wir, wenn am Ende noch Zeit bleibt.

Diese und andere Gründe werden genannt, wieso man keine automatisierten Tests durchführt. Solche Aussagen hört man sogar von Teams, die sich selbst als „agil“ betrachten. Immerhin – die meisten haben von automatisierten Tests gehört, finden das Prinzip sehr gut und erstrebenswert. Dennoch scheint es eher in die Kategorie „Utopia“ zu fallen.

Leider lassen sich selbst in Projekten, in denen Unit-Tests geschrieben werden, nur sehr schwer tatsächliche Aufwände für Tests ermitteln. Zu sehr vermischen sich diese mit Aufwänden für die Entwicklung der zu testenden Anwendung.

Umfangreiche Tests sind schwer zu verkaufen. Sie tauchen in Angeboten dementsprechend nur als kleiner Anteil auf. Diese Verteilung zwischen Applikation und Tests wird an die Entwickler weitergegeben. Fällt die Entwicklung des Moduls oder der Tests unerwartet hoch aus, werden die überschüssigen Stunden nicht auf den Teil gebucht, der länger gedauert hat, sondern auf die Module, die laut Schätzung noch „Stunden offen haben“. So wird die anfängliche Annahme zur Realität auf dem Papier gemacht. Im Nachhinein lassen sich so kaum verlässliche Zahlen ermitteln, die für oder gegen das Schreiben von Tests sprechen würden.

Nun hatte ich jetzt das seltene Glück einmal verlässliche Zahlen zu ermitteln, die bestätigt haben, was ich bereits seit längerem vermutet habe und nie belegen konnte:

Tests zu schreiben geht wesentlich schneller als die zu testenden Klassen.

In einem Projekt mit 12.000 Zeilen Code (Modell- und Controller-Schichten aus dem MVC-Schichtenmodell) wurden nachträglich für „nur“ die kritischsten Kernklassen Tests mit insgesamt 800 Zeilen Code geschrieben. Auch in diesem Projekt hat man (wie so oft) leider auf den positiven und beschleunigenden Effekt der testgetriebenen Entwicklung verzichtet. Jedoch war das Schreiben der Tests zeitlich so klar getrennt, dass man zumindest verlässliche Aufwände festhalten konnte.

Die Entwicklung der Applikation hat insgesamt 300 Stunden gekostet, so dass man durchschnittlich 40 Zeilen Code pro Stunde erreichte, was ungefähr dem üblichen Durchschnitt entspricht.

Das Schreiben der Test hat insgesamt 8 Stunden in Anspruch genommen, was umgerechnet 100 Zeilen pro Stunde bedeutet.

Die Entwicklung von 100 Zeilen Testcode verläuft um einen Faktor von 2,5 schneller, als die Entwicklung von 100 Zeilen des Applikationscode.

Wahrscheinlich fällt dieser Faktor tatsächlich sogar noch höher aus, da hier die Tests für die komplexen Kernklassen mit der Gesamtapplikation verglichen werden. Dabei werden die Kernklassen mit Sicherheit mehr Zeit pro Zeile in Anspruch genommen haben, als die der weniger komplexen Klassen, welche vermutlich schneller entstanden sind und den Durchschnittswert für die Kernklassen besser aussehen lassen. Vermutlich liegt der „Umsatz“ bei den Kernklassen lediglich bei 20-30 Zeilen pro Stunde, was einem tatsächlichem Faktor von 3-5 gleich käme.

Das relativiert die Aussagen über die hohen Aufwände von Tests deutlich. Selbst wenn der Umfang an Zeilen der Tests annähernd so hoch ausfällt, wie der Umfang der Applikation, so liegt der Aufwand für die Tests immer noch weit unter 50% (vermutlich sogar unter 25%).

Dies sollte ein ausreichender Anreiz dafür sein, die Aufwände für das Schreiben von automatisierten Tests separat und (zumindest für interne Statistiken) ehrlich zu erfassen. Denn nur so kann man die Aufwände vergleichen. Die Anzahl der Zeilen zu vergleichen liefert im Allgemeinen ein verzerrtes Bild.

Zum Projekt

Bei diesem Projekt war es wichtig, das die Kernfunktionen stets intakt sind und durch Änderungen nicht beeinträchtigt werden. (Dies war ein Mal der Fall. Die Fehlersuche hat 4 Stunden in Anspruch genommen, weil der Fehler durch zahlreiche manuelle Tests reproduziert werden musste.)

Ein vollständiger Test der Kernfunktionen (so wie er in den automatischen Tests umgesetzt wurde) brauchte vorher 2 Stunden und wurde bis dahin deswegen nur 4 Mal durchgeführt.

Die Erstellung der (wenigen) automatisierten Tests amortisiert sich hier bereits nach 4 kompletten Testdurchläufen. Mehr noch: der automatische Testdurchlauf wird nun täglich durchgeführt, so dass Fehler zeitnah wahrgenommen werden. Die Fehlersuche beschränkt sich nur noch auf den Code, der in den letzten 24 Stunden geändert wurde. Vorher wurden vollständige Tests nur alle zwei Wochen durchgeführt. In der Zeit hat sich viel am Programmcode geändert.

Fazit

Wer die Kernfunktionen einer Applikation nicht durch automatische Tests abdeckt, um die Kosten für deren Entwicklung zu sparen, zahlt fast immer drauf. Tests werden entweder sehr oft durchgeführt und verschlingen viel Zeit – oder sie werden nur selten durchgeführt und kosten Zeit beim Auffinden der Fehler.

Ich will hier jetzt keine endlose Liste von Vorteilen testgetriebener Entwicklung runterbeten. Solche Listen haben die Meisten irgendwann schon einmal gelesen.

Es soll nur so viel gesagt bleiben:

• 1000 Zeilen Tests werden sehr viel schneller geschrieben, als 1000 Zeilen „regulären“ Programmcodes.
• Tests sparen mehr Zeit, als ihre Entstehung kostet – auch wenn es bei der Betrachtung der Anzahl der entstandenen Zeilen anders wirkt.
• Bevor sie sich einfach einem Vorurteil ergeben und aus diversen Gründen auf das Testen verzichten – machen sie sich doch ein eigenes Bild: Erfassen sie die aufgewendeten Stunden für Tests einmal separat. Sich selbst werden sie ja vertrauen können.
• Erzählen sie ihren Mitmenschen anschließend von ihren eigenen Erfahrungen.