Unit-Tests – Zeitverschwendung?

Heute geht es um Unit-Tests, warum sie eine tolle Idee sind und wieso sie trotzdem so selten anzutreffen sind.

Sind Unit-Tests wirklich so gut?

Alle schwärmen von Unit-Tests. Haben Sie schon mal einen Entwickler getroffen, der Ihnen gesagt hat dass Unit-Tests prinzipiell nicht funktionieren? Dass sie Zeitverschwendung sind? Ich nicht. Und wenn alle das sagen, dann muss doch was dran sein, oder?

Allerdings, so ist es. Trotzdem sollten Sie nichts nur deshalb machen, weil alle es so toll finden. Also, warum sind Unit-Tests so gut?

1. Weniger Bugs: Nun, genau genommen sind es noch genauso viele Bugs wie sonst auch, aber man findet sie noch vor der Auslieferung bzw. Testbereitstellung. Und das ist auf jeden Fall eine gute Sache, denn es steigert die Qualität der Software ganz erheblich. Mit all den wünschenswerten Seiteneffekten, die daraus entstehen.
2. Refactoring wird leichter: Waren Sie schon einmal in der Situation, dass sie einen kapitalen Fehler im Design Ihrer Software hatten? Den Sie erst relativ spät bemerkt haben? Einen, von dem Sie wussten, dass er Ihnen noch viel Ärger bereiten wird? Und trotzdem wollten Sie kein Refactoring durchführen, um diesen Fehler zu beheben, weil Sie dann die halbe Anwendung hätten auseinander reißen müssen und die Folgen kaum zu kalkulieren gewesen wären. In so einem Fall sind Unit-Tests ein Segen, weil sie Ihnen genau sagen, wo ihre Anwendung noch funktioniert und wo nicht, ohne dass Sie aufwendige manuelle Tests durchführen müssen. Auf diese Weise können die Entwickler viel mutiger mit notwendigen Änderungen umgehen, als das sonst der Fall wäre.

Wenn Sie Test-Driven Development betreiben (TDD), dann schreiben die Entwickler die Unit-Tests, bevor sie mit dem eigentlichen Code beginnen. In diesem Fall kommen noch zwei weitere Vorteile dazu:

1. Reduzierte Testzeit: Egal unter welchen Umständen, ein Unit-Test wird immer schneller sein als von Hand zu testen. Da Entwicklertests einen wesentlichen Teil des Entwicklungsaufwandes ausmachen (sollten), sparen Sie automatisch einiges an Zeit und verkürzen diese Phase erheblich. Wenn Entwicklertests in Ihrem Projekt eher als homöopathische Beigaben betrachtet werden, dann brauchen Sie Unit-Tests noch viel dringender ;).
2. Besseres Design: Wenn Sie vor dem Coden eines Features einen Unit-Test schreiben, dann müssen Sie sich zwangsläufig Gedanken über die Struktur des Codes machen, also ein Design entwerfen. Mindestens die Schnittstellen nach außen müssen dafür bereitstehen, denn diese wird der Unit-Test benutzen. Allein dadurch wird Ihr Design besser werden.

Unit-Tests vom Aussterben bedroht!

Wenn Unit-Tests so eine tolle Sache sind, warum hat dann nicht jede Software welche? Wie kommt es, dass trotz der vielen Vorteile Unit-Tests immer noch viel zu selten eingesetzt werden? Schauen wir uns einmal an, was gemeinhin an Argumenten gegen sie ins Feld geführt wird.

Keine Zeit (Entwickler)

Unit-Tests sind zunächst einmal eine Investition, da hierfür zusätzlicher Code geschrieben werden muss. Diese Investition zahlt sich später aus, weil beim Testen mehr Zeit eingespart wird als das Erstellen des Unit-Tests gekostet hat. Wenn aber Zeit knapp ist (und sie ist praktisch immer knapp), dann wird der Entwickler jede Möglichkeit nutzen, um sofort Zeit zu sparen – nicht erst später. In diesem Fall entfällt der Entwicklertest komplett oder wird auf das aller nötigste reduziert.

Keine Zeit (Projektleiter)

Im Projektmanagement sind Termine gemeinhin das Wichtigste, ob sie nun Meilensteine oder Deadlines heißen. Wenn der Projektleiter sich zwischen Qualität und Einhaltung des Meilensteins entscheiden muss, dann wird die Qualität fast immer verlieren. Den Termin zu halten hat die oberste Priorität.

Glaubensfragen

Vielleicht sind Sie als Entwickler / Projektleiter absolut überzeugt von Unit-Tests. Sie wissen um die aktuellen Unzulänglichkeiten in der Entwicklung und wollen sie abstellen. Aber dann geraten Sie an so einen Erbsenzähler, der noch nie selber Software entwickelt hat und er fragt:

„Unit-Tests, so so... weniger Zeit, weniger Kosten und bessere Qualität. Das klingt ja wirklich zu schön um wahr zu sein! Können Sie das denn auch beweisen?“

Nein, das können Sie nicht, denn Sie haben keine eigenen Erfahrungswerte (sonst würden Sie dieses Gespräch vermutlich nicht führen). Und außerdem: Wie soll man so etwas eigentlich beweisen? Schließlich können Sie schlecht dieselbe Aufgabe an zwei Teams vergeben, von denen das eine mit Unit-Tests arbeitet und das andere nicht.

Ich glaube nicht, dass Sie den Nutzen von Unit-Tests wirklich beweisen müssen, weil ich denke dass es andere tiefer liegende Gründe für die Skepsis gegenüber Unit-Tests gibt (dazu gleich mehr). Wenn Sie dennoch nach harten Fakten suchen kann ich Ihnen hier zwei Links zu entsprechenden Untersuchungen präsentieren:

Boby George / Laurie Williams: An Initial Investigation of Test Driven Development in Industry

Pancur / Ciglaric: Impact of test-driven development on productivity, code and tests: A controlled experiment

Sogar derartig gut „bewaffnet“ kann es sein, dass Sie folgende Antworten zu hören bekommen:

• „Unit-Tests sind nicht schlecht, aber diese Software ist dafür zu komplex. Wir würden mehr Zeit für die Erstellung und Pflege der Tests verwenden als für die eigentliche Codierung.“
• „Diese Anwendung ist so einfach, dafür lohnen sich Unit-Tests nicht.“
• „Solche Studien laufen unter Laborbedingungen. Im wirklichen Leben sieht das ganz anders aus.“

Auch wenn diese Argumente keine Substanz besitzen, sind sie schwer zu entkräften. Mit Fakten ist solchen Ansichten offensichtlich kaum beizukommen. Ich glaube, dass die Ursache dafür in der Betrachtung und dem Stellenwert von Qualität liegt:

• Alle finden Qualität gut, aber Termine sind wichtiger. Deswegen darf Qualität nichts kosten, und wenn doch dann höchstens Geld aber auf keinen Fall Zeit.
• Wer nicht selbst entwickelt hat, kann die Wirkungen von Unit-Tests schlecht einschätzen. Hier zeigt sich wieder, dass man Erfahrungen nur selber machen aber nicht vermitteln kann.
• Es ist sehr offensichtlich, was man an Zeit investieren muss, um Unit-Tests zu schreiben. Das lässt sich auch recht gut einschätzen. Es ist aber völlig unklar, wie viel Zeit durch Unit-Tests eingespart werden kann. Wie misst man einen Fehler, der nicht mehr auftritt?

Um alle zufrieden zu stellen bräuchten wir Unit-Tests, welche alle bekannten Vorteile liefern, aber keine Zeit für die Erstellung benötigen. Wie macht man das? – keine Ahnung! Allerdings haben wir eine Praxis entwickelt, die dem so nah wie möglich kommt und die ich Ihnen hier kurz vorstellen möchte.

Projektverträgliche Unit-Tests: Die 80/20-Lösung

Um den Einfluss auf das Projektmanagement und die Terminplanung so gering wie möglich zu halten, haben wir die Unit-Tests ein wenig zweckentfremdet: Wir testen eigentlich nicht mehr einzelne Units, sondern zusammenhängende Bearbeitungsschritte, so ähnlich wie ein Anwender das auch machen würde. Man kann sich darüber streiten, ob man einen solchen Test noch als Unit-Test oder automatisierten Systemtest bezeichnen will. Aber das ist hier auch nicht wichtig.

Heute sind die Frameworks für Unit-Tests schon sehr leistungsfähig, damals jedoch hatten wir Schwierigkeiten, die Benutzeroberfläche in die Tests mit einzubeziehen. Ob das machbar ist hängt auch sehr vom Komfort der Entwicklungsumgebung und der verwendeten Programmiersprache ab. Da wir eine recht gut strukturierte 3-Schichten Architektur verwendeten haben wir uns entschlossen, die Unit-Tests direkt auf der Businessschicht aufzusetzen:

Damit haben wir den Zeitaufwand für die Unit-Tests deutlich reduziert. Je bessere Arbeit beim Erstellen des Designs geleistet wurde, desto geringer ist dann auch der Änderungsaufwand für die Unit-Tests, weil die Schnittstellen stabil sind und die Änderungen „unter der Haube“ stattfinden.

Begleitende Maßnahmen im Projektmanagement

Als Projektleiter sollten Sie noch einige begleitende Maßnahmen durchführen, um Probleme durch den Einsatz von Unit-Tests zu vermeiden.

Aufwandsschätzung

Machen Sie Unit-Tests zu einem festen Bestandteil der Aufwandsschätzung und kommunizieren Sie das auch klar gegenüber den Entwicklern (siehe Artikel Schätzprobleme).

Kontrolle

Je nach Selbstdisziplin der Entwickler und abhängig vom Zeitdruck, unter welchem diese stehen, wird es ein mehr oder weniger großes Risiko geben, dass keine Unit-Tests geschrieben oder ausgeführt werden. Vereinbaren Sie zusammen mit dem Team eine Kontrollmöglichkeit, beispielsweise ein Testprotokoll, und definieren Sie wann Kontrollen stattfinden müssen (siehe Artikel Fertig! – Fertig?).

Erfolgsmessung

Messen Sie Ihren Erfolg:

• Erfassen Sie die Fehleranzahl nach Auslieferung, sie sollte beim Einsatz von Unit-Tests deutlich zurückgehen.
• Bestimmen Sie die Länge der Testphase (nach Auslieferung) im Verhältnis zur Entwicklung. Dieses Verhältnis sollte sich zugunsten der Entwicklung verschieben. In den weiter oben verlinkten Studien nahm die Zeit für die Entwicklung zwischen 15% und 35% zu, während die Anzahl der Fehler (und damit auch die Testzeit) um 40% bis 90% reduziert wurde. Mit eigenen Zahlen schaffen Sie auf jeden Fall Glaubwürdigkeit und demonstrieren, dass Sie nicht Argumente aus dem luftleeren Raum ziehen.

Fazit

Ich will nicht behaupten, dass die vorgestellte Lösung perfekt ist. Normalerweise wird sie nur das sogenannte „Main-Success-Scenario“, also den erfolgreichen Standardarbeitsablauf, abdecken bei dem keine weiteren Probleme auftreten. Alternativszenarien und Fehlerfälle mit Hilfe von Unit-Tests zu erfassen ist dann schon entsprechend aufwendiger.

Es gibt aber einen großen Vorteil, der damals auch der Hauptgrund für diese Vorgehensweise war: Die Tests stellen sicher, dass nicht aus Versehen Teile der Anwendung kaputt gemacht werden, die nur indirekt mit dem neuen / geänderten Code in Beziehung stehen. Das ist für die Stabilität der Software sehr wertvoll. Besonders im Zusammenspiel mit der Datenbank (an der auch ständig gebaut wurde) war das eine große Hilfe.