Test Driven Development
Inhaltsverzeichnis
Shift-Left-Approach
Der Ausdruck „Shift-Left“ bezieht sich auf den Zeitpunkt auf einem Zeitstrahl, in dem eine Software getestet wird. Für Entwickler ist es vorteilhaft, wenn Tests möglichst weit links auf dem Zeitstrahl, d. h. so früh wie möglich, stattfinden: Funktionsunfähige Software-Bestandteile werden dann unter Umständen früher erkannt. Diese Vorgehensweise wird als Shift-Left-Approach bezeichnet und verkürzt die Dauer eines Entwicklungs-Projektes unter Umständen deutlich.
Vorgehensweise bei Test Driven Development
Die Vorgehensweise bei TDD besteht aus 3 Schritten, die auch unter dem Begriff „Red-Green-Refactor“ zusammengefasst werden:
- Red (Schritt 1): Unit-Tests, die eine neue Funktionalität testen sollen, werden erstellt. Neue Software-Bestandteile bestehen diese Tests zu Beginn noch nicht – das Ergebnis ist in der Testanzeige rot.
- Green (Schritt 2): Die zu testende Funktion wird solange weiterentwickelt, bis sie die Tests erfolgreich durchläuft.
- Refactoring (Schritt 3): Der geschriebene Quelltext der Funktion wird bereinigt (refactored), um Wiederholungen zu vermeiden und die Code-Konventionen zu erfüllen.
Abb 1. Programmbestandteile werden solange nachgebessert, bis sie die Tests bestehen.
Entwickler wiederholen diesen Prozess so lange, bis die Software alle Tests erfüllt und die gewünschte Funktionalität fehlerfrei ausführt – bei Test Driven Development handelt es sich daher immer um ein inkrementelles Vorgehen, bei dem immer mehr Funktionen hinzugefügt und direkt getestet werden. Verantwortliche sollten bei der Entwicklung immer darauf achten, nur so viel Code anzufertigen, wie zur Erfüllung der Tests notwendig ist. Angefertigte Tests bleiben auch nach einer erfolgreichen Softwareprogrammierung erhalten, damit diese spätere Änderungen direkt prüfen können, um sie bei Erfolg anzuwenden.
Software-Bestandteile so klein wie möglich halten
Die Programm-Bestandteile, die nach ihrer Entwicklung getestet werden, sollten so klein wie möglich gehalten werden. Zum einen ist der Debugging-Aufwand deutlich geringer, weil Verantwortliche Fehlerquellen in kleinen Software-Fragmenten schneller finden, als in großen. Zudem sind Testverfahren für kleinere Programm-Pakete einfacher auszuwerten und zu verstehen.
Vorteile von Test Driven Development
TDD hat viele Vorteile, die bei der klassischen Softwareentwicklung entfallen. So ist die Software besser wartbar, da sie keinen ungetesteten Code und weniger Redundanzen enthält. Der Einfluss von Änderungen auf die bestehenden Funktionen ist sofort nach den Testergebnissen ersichtlich. Weil Fehler durch die Tests sofort auffallen und behoben werden können, verfügt die finale Software über eine hohe funktionale Sicherheit.
Herausforderungen bei Test Driven Development
Trotz der vielen Vorteile, die das Verfahren bietet, gibt es auch Herausforderungen, die Programmierer bei der Anwendung von Test Driven Development bewältigen müssen. Der initiale Aufwand ist gerade für die Entwicklung kleiner und mittlerer Programme hoch. Entwickler müssen zudem die notwendige Disziplin besitzen, sich an jeden Schritt von TDD zu halten. Um die richtigen Unit-Tests anzufertigen, müssen Verantwortliche über das nötige Knowhow, z. B. im Umgang mit ABAP Unit, verfügen. Außerdem müssen Tests sehr atomar, d. h. möglichst einen einzelnen Aspekt betreffend, gestaltet werden, damit eine Programmänderung nicht unnötig viele Tests fehlschlagen lässt.
Test Driven Development erfordert ein Umdenken
In vielen SAP-Entwicklungsprojekten ist es üblich, optimistisch zu entwickeln: Die geforderte Funktion wird dabei erst gebaut und danach getestet. Dabei prüft der Entwickler die Funktionen und ggf. deren Integration in vorgesehene Prozessabläufe und leitet seine Anwendung an den Projektverantwortlichen weiter. Dieser prüft die neuen Funktionen ebenfalls noch einmal.
Test Driven Development hingegen funktioniert komplett anders: Zuerst überlegt sich der Entwickler Testfälle, die er für kleinste technische Anwendungsanteile benötigt und mit denen er prüft, ob diese das richtige Ergebnis liefern. Danach werden die Funktionslogiken entwickelt, um die erdachten Tests erfolgreich zu bewältigen. Eine Änderung der benötigten Funktion zieht auch eine Änderung aller dafür vorgesehenen Tests nach sich: Für Entwickler ergibt sich dadurch ein hoher initialer Aufwand, um gut funktionierende Anwendungen zu programmieren. Dennoch lohnt sich die investierte Arbeit in den meisten Fällen, da die nachträgliche Änderung unzureichend getesteter Funktionen in der Regel noch mehr Zeit in Anspruch nimmt.
Verantwortliche sollten einkalkulieren, dass Entwicklungsprojekte mit TDD gerade am Anfang deutlich mehr Zeit in Anspruch nehmen, als es bei der klassischen Vorgehensweise der Fall ist. Eine gute Konzeption der Anwendung und die Erstellung der Tests führen jedoch zu einer soliden Softwarearchitektur, die später besser gewartet werden kann. Nachträgliche Anpassungen gehen zudem deutlich zügiger vonstatten.
Fazit
Test Driven Development ist eine Vorgehensweise in der Softwareentwicklung, mit der die Shift-Left-Approach umgesetzt und Tests deshalb so früh wie möglich durchgeführt werden. Dabei werden in einem ersten Schritt Testverfahren entwickelt, um die Anwendung in einem zweiten Schritt solange weiterzuentwickeln, bis sie die angefertigten Testverfahren besteht. Damit der Quellcode keine Bestandteile enthält, die nicht zur gewünschten Funktion der Software dienen, wird er im dritten Schritt bereinigt.
Entwickler müssen für eine erfolgreiche Anwendung von TDD alle Schritte konsequent umsetzen und sollten darauf achten, vor allem kleine Software-Pakete zu testen. Denn zum einen sind Fehler dann schneller gefunden und zum anderen lassen sich Testverfahren, die auf kleinere Programm-Fragmente ausgelegt sind, leichter auswerten. Generell erfordert die Umsetzung der Methode viel Disziplin und Knowhow vom Entwickler-Team. Der sichere Umgang mit ABAP Unit ist eine ebenso wichtige Voraussetzung wie eine atomare Gestaltung der Tests. Hierunter versteht man, dass sich diese möglichst auf eine Funktion beziehen, die keine Abhängigkeit zu anderen Programmbestandteilen aufweist. Dies ist entscheidend, da sich Programmänderungen an einer Funktion ansonsten viele andere Tests fehlschlagen lassen könnten.
Die Vorteile von TDD sind vielfältig. Weil der Code so schlank wie möglich gehalten wird, lässt sich die Software besser warten. Der Einfluss von Änderungen am Code ist ebenfalls sofort ersichtlich. Weil Fehler mit dem Verfahren schnell gefunden und behoben werden, verfügt die Entwicklung über eine hohe funktionale Sicherheit.
Kontaktieren Sie uns gerne, wenn Sie weitere Fragen zum Thema Test Driven Development oder ABAP Unit haben und die Theorie in der Praxis umsetzen wollen.
Websession: Test Driven Development
Haben sie Fragen und Herausforderungen zu Test Driven Development? - Dann vereinbaren Sie eine kostenlose Websession mit uns.
FAQ
Was ist TDD?
TDD steht für Test Driven Development. Der Begriff bezeichnet eine Vorgehensweise in der Softwareentwicklung, bei der zuerst sogenannte Unit-Tests und danach die eigentliche Programmlogik entwickelt wird.
Was ist der Shift-Left-Approach?
Der Ausdruck bezieht sich auf den Zeitpunkt auf einem Zeitstrahl, in dem eine Software getestet wird. Für Entwickler ist es vorteilhaft, wenn Tests möglichst weit links auf dem Zeitstrahl, d. h. so früh wie möglich, stattfinden.
