Cacamber als BDD-Framework für ABAP: Ein OSS-Hobbyprojekt unseres Entwicklungsleiters

Szenarien werden in einer speziellen Sprache namens Gherkin geschrieben, wie beispielsweise dieses Szenario für ein Online-Shop-System:

Sie kennen vielleicht schon Gherkin und das GIVEN ... WHEN ... THEN-Muster. Es ist dem ARRANGE ... ACT ... ASSERT sehr ähnlich. Beides sind Techniken, um Unit-Tests eine klare Struktur zu geben.

In ABAP sieht das normalerweise so aus: Der Entwickler wählt eine Funktion aus, erstellt eine Testklasse, gibt der Testmethode einen entsprechenden Namen und schreibt einen Akzeptanztest:

GIVEN wird für die Erstellung des Tests verwendet. WHEN legt fest, welche Aktion durchgeführt wird, und THEN ist für die Durchsetzung verantwortlich.

Aber die GIVEN... THEN... WHEN... Kommentare sind hier nicht sehr hilfreich. Außerdem sind die einzelnen Teile des Tests nicht wiederverwendbar. Und der gesamte Test ist nicht sehr domänenzentriert im Vergleich zu dem Szenario, das das Unternehmen tatsächlich definiert hat.

Also wollten es einige Leute besser machen und begannen, ihre Tests so zu schreiben:

Das ist viel besser! Die meisten Details und die Komplexität sind hinter gut benannten Methoden versteckt – es wurde eine weitere Abstraktionsebene eingeführt. Außerdem gibt es die Möglichkeit, die Testparameter zu ändern. Das macht die Testschritte flexibler und wiederverwendbar.

Die Verwendung parameterloser Methoden würde den Code jedoch lesbarer machen. Doch diese Lösung kommt unserem ursprünglichen BDD-Szenario in keiner Weise nahe. Es handelt sich hier nicht um natürliche Sprache, sondern hauptsächlich um Code. Außerdem wird dieser Ansatz durch die maximale Methodenlänge von ABAP eingeschränkt. Die Entwickler sind gezwungen, Abkürzungen usw. zu verwenden.

Aus diesem Grund beschloss ich, dies zu ändern und ein Open Source Software Hobbyprojekt zu starten. Ich entwickelte eine BDD-Schicht für ABAP namens "Cacamber". Derzeit unterstützt Cacamber englische und deutsche Gherkin-Schlüsselwörter.

Wenn Sie sich entscheiden, Cacamber als Brücke zwischen dem in Gherkin geschriebenen Szenario und ABAP Unit zu verwenden, sehen Ihre Testschritte wie folgt aus:

Wenn der Test fehlschlägt, informiert Sie ABAP Unit auf diese Weise:

Ihre Tests können auch so aussehen:

Oder so:

Wie das funktioniert und wie Sie Ihre eigenen Tests im BDD-Stil in ABAP schreiben können? Im Cacamber Repository gibt es eine umfangreiche Dokumentation und zwei Beispielklassen.

Im Großen und Ganzen gelingt es wie folgt:
Wenn Sie eine von Cacambers Methoden wie GIVEN, WHEN, THEN, etc. oder VERIFY aufrufen, geben Sie einen String als Parameter dieser Methoden an. Dieser String ist ein einzelner Schritt in Ihrem Test (wenn Sie GIVEN etc. verwenden) oder auch ein komplettes Szenario (wenn Sie VERIFY verwenden), geschrieben in natürlicher Sprache. Cacamber nimmt diesen String und vergleicht ihn mit der Konfiguration, die über die Methode CONFIGURE im SETUP Ihrer Testklasse bereitgestellt wurde. Die Konfiguration besteht aus verschiedenen Einträgen. Der erste Eintrag wird verwendet, um zu prüfen, ob der reguläre Ausdruck ("pattern") und die angegebene Zeichenkette übereinstimmen. Ist dies der Fall, extrahiert Cacamber die Variablen aus der Zeichenkette. Dann wird die Methode aufgerufen, die über die Konfiguration bereitgestellt wurde und die Variablen als Parameter verwendet. Stimmt kein regulärer Ausdruck überein, wird der nächste Konfigurationseintrag geprüft, usw. Wenn kein Konfigurationseintrag gefunden werden kann, wirft Cacamber eine Ausnahme.

Hier ein kurzes Beispiel. Schauen wir uns nun an, wie Cacamber den gegebenen Teil unseres Szenarios zerlegt:

Aus der Sicht der Unit-Tests wollen wir einen Vor- und einen Nachnamen erhalten und diese zum Einrichten unseres Tests verwenden. Unsere lokale Testklasse muss von ZCL_CACAMBER erben, damit Sie Cacambers Funktionen nutzen können.

Dann müssen wir Cacamber in der SETUP Methode unserer lokalen Testklasse mitteilen, welche Methode aufgerufen werden soll, wenn ein bestimmter Regex (Abkürzung für regulärer Ausdruck bzw. regular expression) übereinstimmt:

Diese Konfiguration ruft die Methode SET_FIRST_AND_SECOND_NAME auf, wenn der Regex PATTERN passt. Zusätzlich extrahiert sie die beiden Variablen aus dem Platzhalter "(.+)" und verwendet sie als Importparameter für SET_FIRST_AND_SECOND_NAME.

Die Methode sieht wie folgt aus:

Innerhalb dieser Methoden können Sie die eigentliche Logik Ihrer Tests platzieren, zu Beispiel den Aufruf verschiedener Methoden Ihres Geschäftsobjekts.

Sie müssen auch Behauptungen für Ihren Unit Test aufstellen. Normalerweise geschieht dies mit dem Schlüsselwort THEN:

Wir weisen also Cacamber in unserer SETUP-Methode an, die Methode EVALUA-TE_APPLIED_DISCOUNT aufzurufen, wenn der folgende Regex passt:

Die Methode EVALUATE_APPLIED_DISCOUNT sieht wie folgt aus:

So einfach geht's: Definieren Sie ein Muster in der Konfiguration und teilen Sie Cacamber mit, welche öffentliche Methode Ihrer Testklasse aufgerufen werden soll.

Für weitere Details sehen Sie sich bitte die mitgelieferten Beispielklassen an.

Sie fragen sich, wie Sie Cacamber in Ihren Entwicklungsprozess einbinden? Ich empfehle Ihnen wie folgt vorzugehen:

1. Identifizieren Sie die wichtigen Funktionen Ihrer Software und setzen Sie Prioritäten.
2. Identifizieren Sie verschiedene Szenarien für diese Funktionen und priorisieren Sie sie.
3. Definieren Sie Akzeptanztestbeschreibungen für diese Szenarien. Verwenden Sie dazu die Gherkin-Sprache und stellen Sie sicher, dass das gesamte Team sie versteht. Szenarien sind keine technischen Beschreibungen. Sie beschreiben die Absicht des Benutzers, was er tatsächlich tut und was er erreichen will.
4. Schreiben Sie das erste Szenario mit Cacamber, das aus den relevanten Schritten besteht, und setzen Sie ein ASSERT in die THEN-Stufenmethode.
5. Die neue Testmethode wird höchstwahrscheinlich mit einer Ausnahme fehlschlagen, weil die Stufenmethoden nicht implementiert sind oder das ASSERT fehlgeschlagen ist. Sie könnte auch grünes Licht geben, wenn die Stufenmethoden bereits implementiert sind und die vorhandene Geschäftslogik die Kriterien des ASSERTs erfüllt. Dann sind Sie fertig.
6. Wenn das Szenario fehlschlägt, müssen Sie höchstwahrscheinlich eine neue Methode für Ihre Geschäftslogik schreiben. Verwenden Sie dafür Test Driven Development (TDD): Red-Green-Refactor. Wenn Ihre TDD-Tests grün sind, fügen Sie die neu erstellte oder geänderte Methode in Ihre Stufenmethode ein. In einer einzelnen Stufenmethode kann es mehr als einen Methodenaufruf für Ihre Geschäftslogik geben. Sie müssen auch die Ergebnisse Ihrer Geschäftslogik in Attributen speichern, damit andere Stufenmethoden darauf zugreifen können (ein Schritt berechnet einen Wert, der nächste Schritt validiert ihn usw.)
7. Wiederholen Sie den Vorgang, bis Ihr Szenario grün ist.
8. Überarbeiten.
9. Beginnen Sie mit dem nächsten Szenario und verwenden Sie Ihre Stufenmethoden wieder.

Ich hoffe, diese kurze Einführung hat Ihr Interesse geweckt. Ich freue mich auf Ihr Feedback, hier unter diesem Blogbeitrag oder Sie kontaktieren mich in der SAP Community: Dominik Panzer sowie auf Twitter / X: Dominik Panzer.