Wachstum mit Unterstützung: Was testgetriebene Entwicklung mit Gartenarbeit zu tun hat
Auf den ersten Blick haben Softwareentwicklung und Gartenarbeit wenig gemeinsam. Doch wie Pflanzen Stützen brauchen, um kontrolliert zu wachsen, hilft testgetriebene Entwicklung (Test-Driven Development) dabei, Code von Anfang an stabil und verlässlich aufzubauen. Wir erklären die Methode verständlich für Entwickler*innen wie auch Hobbygärtner*innen.
Testgetriebene Entwicklung ist zwar schon lange bekannt, gehört aber in vielen Projekten noch nicht zur gängigen Praxis. Bei makandra haben jedoch einige Kolleg*innen diese Technik fest in ihren Entwicklungsalltag integriert und möchten sie nicht mehr missen. Doch was genau steckt eigentlich dahinter?
Unser Principal Engineer Dominik Schöler erklärt testgetriebene Entwicklung anhand eines Beispiels, mit dem sich nicht nur Entwickler*innen, sondern auch Botaniker*innen (und Hobbygärtner*innen) gut identifizieren können. Denn mal ehrlich: Wer schon einmal eine neue Pflanze gesetzt hat, kennt den Wunsch, dass sie genau so wächst, wie man es sich vorgestellt hat. Dazu brauchen viele Pflanzen eine kleine Stütze: Beispielsweise müssen Tomatenpflanzen oder Weinranken fixiert werden, um sich gut zu entwickeln. Mit Code verhält es sich ganz ähnlich.
Was ist testgetriebene Entwicklung?
Testgetriebene Entwicklung ist eine Methodik, bei der Entwickler*innen die Tests vor dem eigentlichen Code schreiben.
Ursprünglich entstand dieser Ansatz in den 1990ern als Alternative zu den starren und langsamen Entwicklungsprozessen der damaligen Zeit. Der Ansatz zeichnet sich durch kurze Entwicklungszyklen, kontinuierliches Feedback und das Ziel aus, von Beginn an präzisen und stabilen Code zu schreiben.
Es gibt viele Varianten des testgetriebenen Entwicklens: Tests-first Development, Test-driven Development, Behavior-driven Development, Acceptance-driven Development und viele weitere.
Wie sich testgetriebene Entwicklung einfach beschreiben lässt, erläutern wir im Folgenden mit Hilfe einer botanischen Metapher.
Beispiel: Testgetriebene Entwicklung
Stell dir vor, dein Code ist eine Pflanze: Bei der Entwicklung von neuen Features geben die Integration-Tests der Pflanze ihre äußere Form. Wie eine Rankhilfe, die die grobe Richtung vorgibt. Damit ist schon einmal der Rahmen gesteckt, und man kann auf einen Blick sehen, wo es hingehen soll (hier: “nach oben”).
Oft reicht das jedoch nicht, denn möglicherweise tendiert die junge Pflanze dazu, innerhalb ihres Gerüstes umzukippen oder zu schwanken.
Hier kommen die Unit-Tests ins Spiel: Sie funktionieren wie kleine Pflanzenclips, die die Pflanze an bestimmten Stellen festhalten und ihr Verhalten so an einzelnen Stellen eindeutig fixieren.
Dabei ist die richtige Anzahl an Tests eine entscheidende Überlegung.
Denn was passiert bei zu vielen Tests? Die Pflanze ist wie einbetoniert. Natürlich ist ihr Verhalten so perfekt fixiert, doch bei jeder nachträglichen Änderung muss der Beton wieder mühsam aufgebrochen werden. Und was bei zu wenigen Tests? Die Pflanze wuchert unkontrolliert, und bei einem Sturm kann schon einmal ein Zweig abbrechen.
Wichtig ist also, die Pflanze (der Code) an den entscheidenden Punkten zu fixieren. So stellt man sicher, dass sich die Pflanze so entwickelt, wie geplant.
Unser testgetriebener Entwicklungsprozess erklärt
Unser testgetriebener Entwicklungsprozess folgt einem Top-down-Ansatz, bei dem die Tests als Planungshilfe oder als To-Do-Liste dienen:
- Feature aufschreiben
Zunächst alle denkbaren Nutzungsszenarien einzeln, ohne viele Details (also wirklich in simpelster Form) aufschreiben. Ziel ist es, dass alle Funktionalitäten des neuen Features abgedeckt werden (d.h. typische Anwendungsfälle, potenzielles Fehlverhalten, unterschiedliche Zugriffsrechte, Sonderfälle etc.). - Szenarien ausformulieren
Die Szenarien nacheinander mit Details ausformulieren, solange klar ist, wie es weitergeht. - Implementieren
Schritt für Schritt vorgehen und die zuvor ausgearbeiteten Szenarien nacheinander in Code umsetzen. Sobald dabei Code entsteht, der nicht durch einen Integration-Test abgedeckt ist (etwa eine einzelne Funktion, ein Hilfsmodul oder ein spezieller Randfall) sollte gezielt ein Unit-Test dafür geschrieben werden. - Unit-Verhalten aufschreiben
Alle Einzelfälle überlegen, die bei der neuen Funktion eine Rolle spielen können (um Beispiel bestimmte Eingaben, ungewöhnliche Werte, Fehlerfälle oder Hilfsfunktionen im Hintergrund). Auch hier alle wichtigen Aspekte abdecken, aber diesmal auf der Ebene einzelner Bausteine, nicht kompletter Abläufe. - Unit-Tests ausformulieren und implementieren
Einen der oben notierten Fälle ausformulieren. Dann genau so viel Code schreiben, dass dieser Test erfolgreich durchläuft („grün” wird).
Und ja, manchmal fallen uns währenddessen noch neue Testfälle ein, dann gehen wir eben wieder ein, zwei Schritte zurück. Testgetriebene Entwicklung ist kein starres Rezept, sondern eher ein lebendiger Pflanzplan.
Warum wir bei makandra auf testgetriebene Entwicklung setzen
Testgetriebene Entwicklung ist für uns kein Selbstzweck. Sie hilft uns, Anwendungen zu bauen, die nicht nur funktionieren, sondern von Anfang an stabil, wartbar und zuverlässig sind. Durch automatisierte Tests erkennen wir Fehler früh, sichern bestehende Funktionen ab und bringen neue Features sicher ins System.
So wachsen unsere Projekte kontrolliert – aber lebendig. Ganz wie eine gut gepflegte Pflanze.