Aufgrund der ständigen Nachfrage nach schnellerer Entwicklung und Änderung von SAP-Anwendungen war der Bedarf an kontinuierlicher Auslieferung nie größer. Agile Softwareentwicklung, kontinuierliche Auslieferung und DevOps sind bereits seit einigen Jahren bei IT-Unternehmen Standard, und der Bedarf, diese Konzepte nun auch auf SAP zu übertragen, steigt stetig. 

Aber welche Auswirkungen wird dies auf die Entwicklung in SAP haben?

Kontinuierliche Integration

Eines der Hauptkonzepte von DevOps ist das der kontinuierlichen Integration (KI). Wenn der Code geändert wird, werden automatisch Komponententests durchgeführt, um dessen Qualität zu prüfen. Ziel ist es, Probleme und Fehler frühzeitig im Entwicklungslebenszyklus zu erkennen, damit sie später in der Qualitätssicherung oder – schlimmer noch – in der Produktion keine größeren Probleme verursachen.

Die Planung und Durchführung von Komponententests ist zeitaufwendig und mühsam, eine Automatisierungslösung wäre also eine logische Konsequenz. Warum finden wir diese bei SAP dann nicht öfter?

Die SAP-Entwicklung ist anders, aber Komponententests sind auch hier wichtig.

Außerhalb der SAP-Entwicklung gewährleistet die kontinuierliche Integration, dass Änderungen anhand von automatisierten Komponententests geprüft werden, wenn ein Entwickler den lokalen Code in einen zentralen Speicher überträgt. Ist etwas schiefgegangen, werden die Entwickler schnell darüber informiert, so dass sie die notwendigen Lösungen zur Behebung des Problems finden können.

SAP, und insbesondere ABAP, ist anders, da die gesamte Entwicklung in einem gemeinsamen System erfolgt. Änderungen sind sofort sichtbar und betreffen alle.

Komponententests stehen als Standardfunktion in SAP zur Verfügung. Wie können wir sie also effizient verwenden, um KI-Prozesse zu implementieren?

Komponententests und testgetriebene Entwicklung (TDD)

Schauen wir uns zunächst einmal an, worum es bei Komponententests geht. Im Wesentlichen zielen wir darauf ab, zu prüfen, ob sich ein Code bei seiner Erstellung oder Änderung so verhält, wie wir es gerne hätten. Wir versuchen auch zu gewährleisten, dass alle Systeme, die den Code verwenden, richtig funktionieren, wenn der Komponententest bestanden wurde.

Beim Schreiben von Komponententests sind einige Grundprinzipien zu beachten:

• Unabhängigkeit – um sicherzustellen, dass ein fehlgeschlagener Komponententest keine anderen Komponenten beeinträchtigt, müssen alle Tests unabhängig voneinander verlaufen.
• Konsistenz – ein Test muss bei jedem Durchlauf immer dieselben Ergebnisse aufweisen (bei gleichen Testparametern).
• Eine Arbeitskomponente – es ist wichtig, kleine Code-Teile (Komponenten) zu testen, die unterschiedliche Funktionen aufweisen.
• Einbeziehung des gesamten Codes – diese Tests müssen den Nachweis erbringen, dass der gesamte Code inklusive Ausnahmen ausgeführt wird.
• Schneller Ablauf – wenn der Test fehlschlägt, müssen die Entwickler das unverzüglich wissen, so dass sie sich dem Problem widmen können.

TDD geht mit Komponententests einher. Das Konzept lautet, dass der automatisierte Komponententest vor dem Code geschrieben wird – der Test schlägt also zu Anfang fehl, da der Code noch nicht erstellt wurde. Dann wird ein Mindestmaß an Code geschrieben, um den Test zu bestehen, worauf nach Bedarf ein Refactoring erfolgen kann.

Ein neuer Ansatz für die SAP-Entwicklung.

Damit der Komponententest funktionieren kann, müssen wir sicherstellen, dass die Code-Komponenten die richtige Größe haben, um getestet werden zu können. Daraus ergibt sich, dass Codes anders entworfen und geschrieben werden müssen, damit Anwendungen auf Grundlage dieser Einheiten zusammengestellt werden können.

Die traditionelle Programmierung, bei der Hunderte oder Tausende Code-Zeilen geschrieben werden, um eine Anwendungsfunktion auszuführen, ist äußerst schwierig zu testen, da der Code verschiedenen Funktionen dient.

Hier setzt die objektorientierte Programmierung an, bei der Anwendungen in kleinere, wiederverwendbare Objekte und Klassen eingeteilt werden.

Es ist von Vorteil, Entwurfsmuster wie SOLID und insbesondere Single-Responsibility- und Dependency-Inversion-Prinzipien zu befolgen.

Eine eindeutige Verantwortlichkeit in Ihrem Code (d. h. er macht nur eine Sache) verbessert Ihre Fähigkeit, Mock-Objekte in die genauen und isolierten Stellen zu injizieren, wo sie benötigt werden, und verbessert damit die Granularität der zu testenden Objekte.

Ein Code mit umkehrbaren Abhängigkeiten ermöglicht Ihnen den einfachen Ersatz der Bearbeitung von echten Daten durch Injektion Ihres Datengenerator-Objekts für Mock-Komponententests, so dass Sie vorhersehbare Testergebnisse erzielen.

Eine Definition von SOLID finden Sie hier (EN) .

Es kann eine Herausforderung sein, diese Technik anzunehmen, aber solange Klassen richtig entworfen und gebaut werden, ist der Prozess nachvollziehbar.

Tools wie ABAP Unit können dann verwendet werden, um die Komponententests zu entwerfen und zu erstellen. Idealerweise sollten diese Tests automatisch ausgeführt werden, wenn der Code geändert wird, so dass sie alle geprüft werden können, bevor sie an eine andere Stelle verschoben werden. Einige nützliche Beispiele zur Verwendung von APAB Unit finden Sie