Seien wir ehrlich: Test Driven Development (TDD) wird in vielen SAP-Entwicklungsprojekten immer noch etwas stiefmütterlich behandelt - oder wann haben Sie das letzte Mal erst einen Test entwickelt, bevor Sie mit der eigentlichen Umsetzung begonnen haben? Oft ist der erhöhte Aufwand oder das fehlende Wissen Grund dafür, dass auf eine Test-unterstützte Entwicklung verzichtet wird. Welche Vorteile sich jedoch durch den Einsatz von TDD ergeben, erfahren Sie im Folgenden.
Was ist TDD überhaupt?
Mit der Einführung des ABAP-Unit-Frameworks im SAP Release 6.20 ist es möglich, eine testbasierte Anwendungsentwicklung durchzuführen. Damit können Klassen, Funktionsbausteine und ausführbare Programme (oder deren Unterprogramme) automatisiert getestet werden.
Innerhalb des TDD-Prozesses verlassen Sie sich dabei ausschließlich auf die von Ihnen geschriebenen Tests, um damit die Funktionalität des Produktionscodes zu validieren. Dazu werden zunächst alle Methoden, Funktionsbausteine oder Programme, die getestet werden sollen, angelegt, ohne diese mit Coding zu füllen. Anschließend wird die lokale Testklasse angelegt, die die eigentlichen Tests als Methoden enthält. Diese Tests sollten jedoch zunächst alle fehlschlagen („Rot"), da die eigentliche Implementierung noch fehlt. Erst im letzten Schritt wird so lange implementiert und optimiert bis alle Tests erfolgreich durchlaufen werden („Grün").
Warum zuerst den Test entwickeln?
Der Vorteil, erst den Test zu entwickeln, besteht darin, dass Sie sich zuerst über verschiedene Aspekte der Anforderung Gedanken machen müssen, bevor Sie mit der Umsetzung beginnen: Was muss meine Methode können? Welche Parameter braucht meine Methode? Wie soll sich die Methode in einem Spezialfall verhalten?
Auch gilt es, sich mit den Ergebnissen zu beschäftigen. Wenn ich Zahl X und Y übergebe, sollte der erwartete Wert Z zurückkommen. Diese Erwartungen können nun schon in der Testklasse festgehalten werden, bevor die eigentliche Umsetzung begonnen hat. Es ist natürlich auch möglich, mehrere Teste für eine einzelne Produktivmethode zu schreiben; die Wahl der richtigen Tests ist dabei natürlich für das Endergebnis entscheidend.
Wann ist der Einsatz von TDD sinnvoll?
Grundlegend kann man sagen, dass sich der Einsatz von TDD immer lohnt, besonders jedoch, wenn Grundfunktionalitäten entwickelt werden, die später von anderen Programmen / Klassen genutzt werden sollen. Man stelle sich vor, es soll eine Methode entwickelt werden, die Zahlen miteinander addiert und das Ergebnis zurückgibt. Wenn sich nun in diese Methode ein Fehler einschleicht, wären damit auch alle Programme / Klassen fehlerhaft, die diese Methode verwenden. Man könnte meinen, diese eine Methode ließe sich doch auch in der Testumgebung händisch überprüfen? Das stimmt, jedoch muss immer wieder erneut händisch überprüft werden, sobald die Methode angepasst / verändert wird. Und was ist, wenn wir statt einer Grundfunktion zehn verschiedene Grundfunktionen entwickeln sollen? Spätestens dann wird klar, dass sich der Aufwand eines automatischen Tests lohnt, bei dem man per Modultest alle Testfälle auf einmal durchführen kann und auf einen Blick sieht, ob die Anpassung alle gestellten Kriterien weiterhin erfüllt.
Auch wenn ein anderer Entwickler zu einem späteren Zeitpunkt die Aufgabe erhält, die bestehenden Methoden anzupassen bzw. zu erweitern, sind fehlerhafte Logiken durch TDD sofort sichtbar .
Fazit
Der Einsatz von Test Driven Development lohnt sich immer dann, wenn komplexere Sachverhalte abgebildet und grundlegende Funktionalitäten entwickelt werden sollen. Zwar ergibt sich zunächst ein erhöhter Aufwand bei Planung und Anlage der Tests, dieser kann aber durch die Auseinandersetzung mit der Umsetzung und dem einfachen Testen aller Komponenten schnell wieder aufgeholt werden. Außerdem ergibt sich durch den Einsatz von TDD eine höhere Codequalität und auch die spätere Wartbarkeit wird durch schnelle Überprüfung verbessert. Zumal die SAP einem die Anlage der Testklassen durch den mitgelieferten Testklassen-Wizard sehr vereinfacht.