TDD und Spezifikation – ein Praxisbericht


Verbreitet die Message!

Als Software-Entwickler ist es mir sehr wichtig guten Code zu schreiben. Ich habe bereits in Projekten gearbeitet, in denen es weder eine Zeile Test gab, noch eine Spezifikation, noch eine Dokumentation. In diesen Projekten war der Verlauf leider auch genauso wie für unwartbare Projekte beschrieben: Der Wartungsaufwand wird schon während der Entwicklung derart hoch, dass das Projekt mit häufigen Änderungswünschen Gefahr läuft gänzlich zu scheitern. Als ich gewechselt bin, war meine Hauptmotivation endlich professionell zu arbeiten und all diese Vorgehensweisen – wie Test Driven Development (TDD) und Dokumentation – auch anzuwenden.

Test Driven Development

Ich arbeite zur Zeit in einem Projekt, in dem die Test-Coverage ca. 85% beträgt – da ich die ersten Zeilen Code mitschrieb, konnte ich auch für diese Test-Coverage sorge tragen. Wir testen die interne Funktionalität von Model-Klassen, bauen Unit und Integrations-Tests für Services und Repositories und testen sogar einen Teil des Frontends. Ich freue mich, dass meine Intuition bei meinem vorherigen Arbeitgeber genau richtig war: Die fehlende Test-Coverage störte mich von Beginn an und machte mich unzufrieden, denn die typischen Symptome traten auf: unbemerkte Regression, schwer zu behebende Fehler, unbemerkte fachliche Fehler. Ich machte diese Situation für meine Unzufriedenheit verantwortlich, war mir aber nie sicher ob ich einfach gerade nur Fan einer Technologie (TDD) geworden war und im Prinzip keine Ahnung hatte – so wie jemand der Linux pauschal in alle Himmel lobt und alles andere verteufelt – oder ob ich mit meinem Faible für automatisierte Tests Recht hatte. Und ich hatte Recht. Immer wenn ich fachliche Fehler erkenne, Regression verhindere oder wir etwas refactoren wollen und ein gutes Gefühl haben können, weil wichtige Dinge so funktionieren wie vorher, wusste ich, dass ich Recht hatte. Und ich bin sehr froh, dass ich den Kampf um Tests (und damit um langfristiges Denken) nicht mehr führen muss.

Spezifikation

Zusätzlich spezifizieren wir unsere Features doppelt: einmal fachlich und darauf aufbauend technisch. In der fachlichen Spezifikation baut man ein hervorragendes Verständnis für den fachlichen Ablauf, für die Wünsche des Kunden und für die Herausforderungen des Features auf. Auf der einen Seite hat man einen gewissen Spielraum Features und Umsetzungen auszuhandeln (oder besser zu umgehen), auf der anderen Seite bauen sich auch schon Vorstellungen für die technische Umsetzung auf, die dann in der technischen Spezifikation realisiert oder umgeworfen werden. 

Zu Beginn der technischen Spezifikation erarbeite ich den grundsätzlichen Workflow des Features und treffe grobe Design-Entscheidungen in Absprache mit meinem Team. Beispielsweise habe ich folgende folgende Fragen geklärt: Sollte die GUI eine SPA sein? Sollte die gewünschte Filterung auf DB-Ebene oder auf Service-Ebene geschehen? Wie wiederverwendbar sind einzelne Komponenten, wie sieht die Architektur im Allgemeinen aus?

Auf dieser Grundlage kann ich dann direkt die Schnittstellen des Features an die restliche Anwendung entwerfen. Spätestens hier treffe ich dann oft auf Probleme, die zu einer Anpassung im vorhandenen Code führen werden, wenn beispielsweise ein benötigtes Property noch gar nicht vorhanden ist. Es ist also Zeit mit den anderen Teammitgliedern über Anpassungen zu sprechen.

Im nächsten Schritt beginne die innere Logik der Funktionalität zu beschreiben – die Kunst ist es dabei den richtigen Detailgrad zu finden. Ich denke es ist eine gute Idee, den Ablauf (wie werden Daten geholt und verarbeitet) dem Software-Entwickler zu überlassen und statt einer low-level Beschreibung lediglich anzugeben, wie welche Daten berechnet werden. Also den Datenfluss und Rechenvorschrift zu bestimmen.

Als letzten Schritt gehört zur Spezifikation das Herausarbeiten der Testfälle, die je nach Featuregröße und Funktion eher fachlich oder eher technisch sein dürften. Damit schließt sich der Kreis zum Testgetriebenen Entwickeln – vor der ersten Code-Zeile, sind die Testfälle bereits klar. Damit dient die technische Spezifikation auch als (Teil-)Dokumentation der Software.

Ein gutes Maß der Qualität der Spezifikation ist, wenn nun ein neues Teammitglied zum Team dazu stößt und es in dem “Wiki” (bspw. Confluence) zumindest soviel Informationen findet, dass es die richtigen Fragen stellen kann. Schlecht ist es, wenn es das Wiki intuitiv nicht benutzt.

Zusammenfassung

Es ist den meisten Entwicklern klar, dass testen und dokumentieren Teil gewissenhafter Arbeit ist, dennoch wird es sehr oft nicht oder nicht ausreichend umgesetzt. Meine Ideen dazu, warum das so ist, und manuell getestet wird anstatt testgetrieben zu entwickeln, habe ich an anderer Stelle beschrieben. Allgemein denke ich, dass dies weniger Entscheidungen von Software-Entwicklern selbst sind, weil diese vielleicht zu faul oder schludrig sind, sondern eher von Führungskräften die schnelle Resultate wollen (und bringen müssen). Letztlich führt aber der langfristige Weg zum langfristigen Erfolg und der kurzfristige langfristig in die Wartbarkeitshölle.

Verbreitet die Message!

Schreiben Sie einen Kommentar