Projektmanagement Softwareentwicklung

Softwareentwicklung f√ľr Projektleiter, Manager und Entwickler

IT-Projektmanagement RSS
  • Unit Tests: Zeitverschwendung?

    Jörg Hinrichs

    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

    Nagappan et alt.: Realizing quality improvement through test driven development

    Sogar derart 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 Erstellungen 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:

     

    Unit-Tests: Architektur

     

    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.

    4 Comments

4 Responses to “Unit Tests: Zeitverschwendung?”

  1. [...] JUnit Test 4 √úbersicht mit Beispiel Veröffentlicht von Alexander Gr√§sel in Java / Java EE, Programmierung, Softwareentwicklung27 Sep, 2011 | 2 Kommentare JUnit ist eines der wichtigsten Tools, die man als Java-Entwickler beherrschen sollte. Es erleichtert das Testen von Java-Klassen und ist zu 100% in Eclipse integriert! Anhand einer Beispiel-Klasse erkl√§re ich den Aufbau und die Funktionsweise von JUnit Test 4. Warum man eigentlich JUnit nutzen sollte, erl√§utert J√∂rg Hinrichs in seinem Artikel “Unit Tests: Zeitverschwendung?”. [...]

  2. [...] Unit Tests: Zeitverschwendung? [...]

  3. “Die Unit-Tests direkt auf der Businessschicht aufzusetzen.”

    Ihr habt wahrscheinlich mit Integrationstests gearbeitet, die √ľbrigens auch wertvoll sind. Viele kleine, fokussierte Unit-Tests sind noch wertvoller.

    Mit der Zeit ist man mit Unit-Tests gar nicht so langsam unterwegs, es braucht allerdings einiges an √úbung.

  4. Ihr habt wahrscheinlich mit Integrationstests gearbeitet

    Genau.

    Mit der Zeit ist man mit Unit-Tests gar nicht so langsam unterwegs

    Habt ihr da Erfahrungswerte, wieviel Overhead durch die Pflege von Unit-Tests entsteht?

Leave a Reply