043: Modern, solid and testable ABAP Code (Part 4)

In den bisherigen Folgen haben wir uns angeschaut, wieso ABAP immer noch eine wichtige Programmiersprache ist, welche Pattern es gibt und wie wir sie sinnvoll einsetzen können und wie wir Unit Tests bauen, die dann wiederum auf diesen Pattern basieren und uns damit einen Mehrwert schaffen. In dieser Folge schauen wir uns noch einige Tipps an, die du für deinen Alltag brauchen kannst, wenn du mit ABAP Unit Tests und deinem eigenen Entwicklungsflow arbeiten möchtest.

Tools

Welche wichtigen Werkzeuginformationen findest du eigentlich im Internet, die dir tagtäglich dabei helfen können, deinen Code zu verbessern, deinen Programmierstil zu vereinfachen oder auch alte Dinge zu entfernen? Dabei solltest du dir vor allem den „Clean ABAP“-Styleguide anschauen. Dies ist ein GitHub-Repository, welches von der Community befüllt wurde und die gängigsten Programmier-Patterns und Best Practices in einem Dokument vereint. Dort findest du Dos und Don’ts, die dir in der täglichen Entwicklung helfen sollen. Welche Statements du nutzen solltest, wie sie aufgebaut sind und was die Best Practices sind, wenn du objektorientierten, wartbaren Code bauen möchtest. Das Dokument ist relativ lang. Hier hilft es, sich einmal einen groben Überblick zu verschaffen, das Dokument vielleicht einmal ganz zu lesen und später dann immer wieder nachzuschauen, wenn du Fragen hast oder dir bei Dingen unsicher bist.

Als Nächstes empfehlen wir den ABAP Cleaner, ein Plugin für die ABAP Development Tools beziehungsweise Eclipse. Mit diesem Plugin erhältst du automatisch eine sehr große Anzahl von Regeln, die deinen Quellcode nach der Entwicklung direkt formatieren können. Dadurch bekommst du schneller einfacheren Code, der auch dem Standard entspricht, ohne viel Aufwand in die eigentliche Formatierung stecken zu müssen. Grundsätzlich funktioniert der ABAP Cleaner so ähnlich wie der Pretty Printer in der Vergangenheit, nur dass hier noch mehr formatiert wird und teilweise auch veraltete Statements oder zu komplexe Anweisungen automatisch vom Cleaner bereinigt werden. So sparst du dir sehr viel Aufwand und Energie, wenn es um die Bereinigung von Quellcode geht. Mit einem einzigen Tastendruck ist dein Quellcode so sauber wie der deiner Kollegen. Grundsätzlich können Varianten und Einstellungen innerhalb der Teams geteilt werden. So bist du nicht der Einzige, der es nutzt, sondern alle im Team verwenden die gleiche Variante und der Code sieht entsprechend einheitlich aus. Das hilft enorm bei der späteren Wartung, denn Code wird viel häufiger gelesen, als dass er geschrieben wird. Ein gleichmäßig formatierter Code, der für alle gut lesbar ist, ist schließlich auch sehr gut wartbar.

Hast du dir das Dokument angeschaut und den ABAP Cleaner installiert? Dann gibt es noch codePal, ein Open-Source-Projekt für das ABAP Test Cockpit. Damit kannst du zusätzliche Prüfungen im System laufen lassen, die überprüfen, ob dein Code auch dem Clean-ABAP-Styleguide entspricht. Das ist unheimlich praktisch, wenn ihr euch im Team auf einen gemeinsamen Standard committet habt. So wird bei der Freigabe direkt noch einmal geprüft, ob alles den Richtlinien entspricht. Vielleicht hat ein Kollege den ABAP Cleaner vergessen oder etwas anders formatiert, hier hilft das ABAP Test Cockpit konkret dabei, noch einmal die letzte Qualitätssicherung durchzuführen. Grundsätzlich können natürlich auch Build-Pipelines auf Basis dieser Varianten gebaut werden. So wird Code, der ins Testsystem läuft, automatisch geprüft, gegebenenfalls bereinigt und erst dann entsprechend deployed.

IDE Actions

Eine sehr spannende Entwicklung der letzten Jahre sind vor allem die ADT Actions, die in die ABAP Development Tools integriert wurden. Damit hast du die Möglichkeit, eigene IDE Funktionalitäten einzubinden oder die IDE um bestimmte Automatisierungstechniken zu erweitern, ohne dabei ABAP zu verlassen. Schauen wir zum Beispiel auf den Teil davor, in dem wir uns gefragt haben: Wieso solltest du eine Factory und einen Injector aufbauen? Grundsätzlich dauert es relativ lange, bis diese Objekte im System implementiert sind. Wir müssen das Interface anlegen, die eigentliche Klasse programmieren und sowohl die Factory als auch den Injector aufsetzen. Das sind einige Objekte, die wir von Hand anlegen müssen, die wiederum Beziehungen untereinander haben und deshalb einiges an Zeit kosten, bevor wir mit der eigentlichen Entwicklung starten können. Da wir Entwickler glücklicherweise meistens faul sind, können wir diesen Schritt natürlich automatisieren. Das muss nicht unbedingt mit KI passieren, sowas klappt auch schon relativ heuristisch mit einer einfachen Struktur und einem entsprechenden Generator. Dafür findest du mit MIA (My IDE Actions) ein Open-Source-Projekt welches dir einige Standards bietet. Eine davon ist zum Beispiel die Generierung von Klassen und ihren Abhängigkeiten. Damit kannst du dir all die benötigten Klassen automatisch erzeugen lassen und theoretisch optional angeben, wenn du bestimmte Objekte nicht haben möchtest. Das Framework übernimmt nach Abschluss der Generierung sogar die Aktivierung der Objekte für dich, sodass du direkt mit der eigentlichen Programmierung beginnen kannst und dir die wiederkehrende Arbeit sparst.

Unit Tests

Wir hatten ebenso einen Abschnitt über das Thema Unit Tests und wie wir diese bauen und noch besser automatisieren können, wenn wir zum Beispiel Injectors verwenden, um damit unseren eigentlichen Quellcode nicht mehr anpassen zu müssen. Genauso sieht es aus, wenn es um das Thema reguläre Tests geht: Haben wir die Tests einmal gebaut, sollten wir sie auf jeden Fall während der Entwicklung manuell ausführen, um immer wieder zu prüfen, ob unsere eigentliche Implementierung noch fehlerfrei arbeitet. Dies beschränkt sich in den meisten Fällen aber auf die lokale Klasse mit der eigentlichen Implementierung oder maximal auf das Paket, in dem wir gerade entwickeln. Die Tests sind schnell ausgeführt und liefern uns somit ein schnelles Feedback, um direkt daran weiterarbeiten zu können.

Als zweite Säule haben wir die Prüfung bei der Freigabe des Transports. Das heißt, das ABAP Test Cockpit kann zum Beispiel übernehmen, dass automatisch alle Unit Tests mit ausgeführt und geprüft werden, während wir die Freigabe des Transportauftrags durchführen. Das Ganze gibt es auch in der Cloud als APIs, das heißt, wir können diesen Schritt in Build-Pipelines einbauen und automatisch prüfen lassen, ob unser Code entsprechend noch sauber ist und die Unit Tests fehlerfrei laufen. Grundvoraussetzung dafür ist aber auch, dass die Tests isoliert aufgebaut sind und möglichst performant ausgeführt werden können, ohne Abhängigkeiten zum eigentlichen Systembestand zu haben.

Dann haben wir noch das Thema der automatischen Ausführung von Unit Tests. Das heißt, wir führen regelmäßig Unit Tests über ganze Pakete oder vielleicht sogar für das komplette System aus, um zu validieren, ob das System noch in einem fehlerfreien Zustand ist oder ob es zum Beispiel durch Änderungen innerhalb des Systems Probleme an einer ganz anderen Stelle gibt. So können wir zum Beispiel ein Interface oder eine Struktur ändern, was wiederum keine Auswirkungen auf unsere lokalen Tests hat, da wir diese entsprechend angepasst und erweitert haben. Aber vielleicht verwendet jemand anderes in seiner Entwicklung genau diese Struktur, sodass seine Entwicklung nun auf Fehler laufen würde. Daher macht es durchaus Sinn, Unit Tests auch über das eigene Paket hinaus regelmäßig laufen zu lassen, um das Gesamtsystem zu validieren. Für On-Premise-Systeme gibt es dafür den ABAP Unit Runner, ein einfacher Standard-Report, der im System läuft und als Hintergrund-Job eingeplant werden kann, um die Unit Tests automatisiert auszuführen und das Ergebnis als E-Mail zuschicken zu lassen. Möchtest du das Ganze in der BTP durchführen, zum Beispiel auf einem Steampunk-System? Dort brauchst du allerdings entweder eine Build-Pipeline oder du nutzt ein Open-Source-Projekt, um die automatische Ausführung von Unit Tests zu triggern und dir auch dort eine E-Mail zukommen zu lassen. Grundsätzlich empfehlen wir die regelmäßige Ausführung, zum Beispiel einmal am Tag, um sicherzustellen, dass alle Unit Tests im System weiterhin sauber durchlaufen.

Hier haben wir noch einmal den Vergleich beider ABAP Unit Runner, einmal für On-Premise und die Private Cloud sowie die Open-Source-Variante für die Public Cloud. Der ABAP Unit Runner im Standard wird per Report gestartet, während die Open-Source-Variante als Application Job läuft, da in der Cloud keine Reports mehr zur Verfügung stehen. Grundsätzlich findest du in beiden Tools die gleichen oder ähnliche Einstellungen, die du nutzen kannst, um den Job einzuplanen. In beiden Varianten kannst du auch eine E-Mail-Adresse hinterlegen, um dir die entsprechenden Informationen über den Testlauf zusenden zu lassen. Der zweite Screenshot vergleicht noch einmal die Aufbereitung des Testergebnisses: Hier findest du auf der einen Seite die Mail über den ABAP Unit Runner mit den entsprechenden Ergebnissen und auf der anderen Seite die E-Mail, die noch einmal zusammenfassend die Ergebnisse über Laufzeiten und die ausgeführten Tests liefert. Grundsätzlich lohnt es sich, einen ABAP Unit Runner immer über das gesamte System laufen zu lassen, um möglichst alle Unit Tests zu validieren, ohne viel manuellen Aufwand in die eigentliche Wartung stecken zu müssen. Stattdessen prüfst du einfach regelmäßig, ob das gesamte System und die darin laufenden Unit Tests sauber sind und fehlerfrei funktionieren.

Conclusion

Das bringt uns eigentlich auch schon zum Ende dieser kompletten Serie. Deshalb wollen wir noch einmal die drei wichtigsten Punkte zusammenfassen: Die Wichtigkeit von ABAP bleibt weiterhin bestehen, auch in der Zeit von RAP und KI. Es wird weiterhin sehr viel ABAP entwickelt werden, um die komplette Business-Logik im System abbilden zu können. Dabei bleibt gutes Design weiterhin in der Verantwortung des Entwicklers. Wenn hier keine sauberen Strukturen entstehen, leiden sowohl die Wiederverwendbarkeit als auch die Testbarkeit im System. KI kann hier zwar helfen, Unit Tests zu automatisieren, zu verbessern und gut lesbarer zu machen, aber grundsätzlich sollte hier die finale Entscheidung weiterhin beim eigentlichen Entwickler bleiben.

Wir haben uns das Thema Pattern angeschaut, die ein wichtiger Bestandteil der ABAP-Architektur in einem System sind. Eine korrekte Anwendung und eine korrekte Nutzung helfen dir dabei, die Testbarkeit zu verbessern und diese ohne größeren Anpassungsaufwand im System herzustellen. Dabei haben wir die Standard-Pattern gezeigt, die man so im alltäglichen Gebrauch verwenden kann, um Code zu entkoppeln und in sauberen Objekten zu verpacken.

Der dritte Punkt ist das Thema Testen. Dabei sollten Unit Tests das Minimum an Standard sein, um saubere Entwicklung durchzuführen. Diese helfen dir dabei, spätere Anpassungen schneller durchführen zu können und immer wieder Validierungen zu haben, die dir helfen, Code schnell zu erweitern. Regelmäßige Tests, die im System laufen, helfen dabei, das gesamte System zu prüfen und mögliche Seiteneffekte frühestmöglich zu erkennen und zu beheben. Weiterhin helfen Tests, auch wenn das Testen eigentlich weiter hinten im Prozess ausgelagert ist, bei der schnelleren Weiterentwicklung des Systems. Sie geben einem neuen Entwickler ein Sicherheitsnetz, wie er die Ressourcen lesen, aber sie auch erweitern kann, ohne dabei Angst haben zu müssen, dass er etwas kaputt macht.

Daher danke ich dir für die Aufmerksamkeit, die du heute und in der gesamten Serie mitgebracht hast! Auf der linken Seite findest du den QR-Code zum Download der verschiedenen Ressourcen wie der Präsentation, den Materialien, den Quellcodes und den weiteren Artikeln, die als Referenz für diesen Beitrag genutzt wurden. Auf der rechten Seite findest du mein LinkedIn-Profil, wenn du dich verknüpfen willst, weitere Fragen hast oder einfach auf dem aktuellsten Stand bleiben möchtest, wenn es um neue Artikel und Informationen geht. Von daher: Danke fürs Zuschauen und bis zum nächsten Mal!

Weitere Referenzen:
YouTube - Part 4
GitHub - Beispiele