Mit dem ABAP Unit Test Framework lassen sich einzelne ABAP Code Abschnitte automatisch testen. Das Framework eignet sich nur zum Testen klar abgegrenzter Code Abschnitte wie etwa einen Funktionsbaustein, ein Bapi oder eine Methode einer Klasse. Das Framework ist nicht geeignet, einen vollständigen Report oder ähnlich komplexe Codes zu prüfen.

In dieser Serie von Beiträgen möchte ich die Grundlagen und die Verwendung des Unit Test Frameworks beschreiben.

1. Grundlagen zum Unit Test
2. Erstellen von Testklassen per Wizard
3. Implementieren einer Testklasse mit Testdaten
4. Aufrufen und Auswerten eines Tests
5. Datenbankzugriffe in Testklassen
6. Systemeinstellungen

ABAP Unit Test Grundlagen

Damit ein Test durchgeführt werden kann, muss zunächst eine Testklasse implementiert werden. Hierbei handelt es sich um eine Klasse, welche mit dem Zusatz FOR TESTING als Testklasse definiert wird. Innerhalb der Testklasse wird der Testumfang definiert. Konkret werden hier Testdaten erstellt und der eigentliche Aufruf des zu testenden Codes, beispielsweise den Aufruf des zu testenden Funktionsbausteins, implementiert.

Das Unit Test Framework nutzt die Testklasse zum durchführen des Tests.

Testklasse

Eine Testklasse besteht aus Methoden zum Vorbereiten der Tests sowie Methoden, welche den eigentlichen Test, sprich den Aufruf des zu testenden Codes enthalten.

Eine Testklasse wird an dem zu testenden Code Abschnitt implementiert. Soll beispielsweise ein Funktionsbaustein getestet werden, wird die Testklasse in einem Include der Funktionsgruppe implementiert. Das bedeutet, auch eine Testklasse wird in ein Produktivsystem transportiert, da sie Bestandteil der Funktionsgruppe ist. Die Testklasse kann in der Regel aber nicht in einem Produktivsystem aufgerufen werden, die Implementierung wird also ignoriert.

Methoden der Testklasse

Folgende Methoden stehen zum Bereitstellen von Testdaten und sonstige vorbereitende Schritte zur Verfügung. Die Methoden werden als Fixture bezeichnet.

Methode	Art	Beschreibung
CLASS_SETUP	Statisch	wird beim Starten des Testlaufs aufgerufen
CLASS_TEARDOWN	Statisch	wird beim Ende des Testlaufs aufgerufen
SETUP	Instanz	wird vor dem Aufruf einer Testmethode aufgerufen
TEARDOWN	Instanz	wird nach dem Aufruf einer Testmethode aufgerufen

Die eigentliche Testmethode wird mit dem Zusatz FOR TESTING versehen.

Aufrufreihenfolge

Um den Verwendungszweck der einzelnen Methoden zu erläutern, sehen wir uns zunächst die Aufrufreihenfolge der Methoden der Testklasse durch das Framework an (Quelle: help.sap.com). Die Methoden werden automatisch von dem Framework aufgerufen, es müssen (dürfen) also keine Methodenaufrufe implementiert werden.

Wie zu sehen wird nach dem Constructor der Testklasse die statische Methode CLASS_SETUP aufgerufen. Sie dient dazu, Objekte oder Testdaten zu erstellen, die von allen Testmethoden verwendet werden (z.B. statische Attribute versorgen). Die Methode wird innerhalb des Unit Tests nur an dieser Stelle aufgerufen.

Anschließend erstellt das Framework für jede Methode der Testklasse, die mit dem Zusatz FOR TESTING deklariert ist, eine eigene Instanz der Testklasse.

Nun wird die Methode SETUP aufgerufen. Hier werden nun alle Objekte, Testdaten etc. erstellt, die genau für diesen Test benötigt werden. Innerhalb der Testmethode wird auch ausgewertet, ob der Test erfolgreich war oder nicht.

Die Aufrufreihenfolge der Testmethoden kann nicht festgelegt werden. Sie werden alphabetisch nacheinander aufgerufen. Auf Abhängigkeiten zwischen den Testmethoden ist also zu verzichten. Wenn mehrere Methoden zu einem Test gehören, müssen die Aufrufe in einer Testmethode zusammengefasst werden.

Nach dem Aufruf der eigentlichen Testmethode wird die Methode TEARDOWN aufgerufen. In dieser können nun alle erstellten Objekte, Datensätze und ähnliches gelöscht werden. Sie dient zum Aufräumen nach einem einzelnen Test.

Wurden alle Testmethoden durchlaufen, wird die Methode CLASS_TEARDOWN aufgerufen. Auch diese dient zum Aufräumen.

Beispiel einer Testklasse

CLASS zs_unit_test DEFINITION FOR TESTING
DURATION SHORT
RISK LEVEL HARMLESS

PRIVATE SECTION.

CLASS-METHODS: class_setup.
CLASS-METHODS: class_teardown.
METHODS: setup.
METHODS: teardown.
METHODS: z_my_test FOR TESTING.

ENDCLASS.

Das Beispiel zeigt die Testklasse ZS_UNIT_TEST. Durch den Zusatz FOR TESTING wird sie als Testklasse deklariert. Sie lässt sich somit nicht ohne weiteres instanziieren.

Die Zusätze DURATION SHORT und RISK LEVEL HARMLESS dienen zur Steuerung des Verhaltens des Frameworks.

Neben den Fixture Methoden (setup und teardown) gibt es noch die Methode z_my_test, welche mit dem Zusatz FOR TESTING als Testmethode deklariert wird. Alle Methoden mit diesem Zusatz werden vom Framework als Testfall behandelt (siehe Abbildung oben).

Die Auswertung, ob ein Test erfolgreich war oder nicht, findet in der eigentlichen Testmethode statt. Dies erfolgt mit den statischen Methoden der Klasse CL_ABAP_UNIT_ASSERT. Diese vergleichen den übergebenen Wert mit dem erwarteten Wert. Stimmen diese nicht überein, wird eine Meldung ins Testprotokoll geschrieben. Hier ein Beispiel mit der Prüfung des SUBRC

" SUBRC auswerten und Assert werfen, falls Test fehlgeschlagen ist
cl_abap_unit_assert=>assert_subrc(
act   = sy-subrc
exp   = 0
quit = IF_AUNIT_CONSTANTS=>NO " Im Fehlerfall nicht die Methode verlassen
msg   = 'gescheitert'
).

Im nächsten Beitrag zeige ich, wie man mit dem Unit Test Wizard unkompliziert Testklassen erzeugen kann ABAP Unit Test Wizard.