Show TOC Anfang des Inhaltsbereichs

Hintergrunddokumentation Wie ABAP Unit Tests funktionieren Dokument im Navigationsbaum lokalisieren

Der Aufbau von Unit Tests

Die Testeinheit (TEH) in ABAP Unit kann eine Klasse, ein Function-Pool, ein ausführbares Programm oder ein Modul-Pool sein. Sie können ABAP Unit für Tests einzelner TEHs vom Class Builder (SE24), dem Function Builder (SE37), dem Programmeditor (SE38) und der SE80 aufrufen. Massentests sind vom Code Inspector aus möglich.

Sie organisieren Ihre Tests in Testklassen und dort in Testmethoden, die alle Teil der TEH sind. Geprüft werden kleine Einheiten innerhalb der TEH, eben die so genannten Units. Ziel einer Testmethode ist es zu prüfen, ob eine Unit das gewünschte Ergebnis liefert. Zu diesem Zweck gibt es die Methoden der Serviceklasse CL_AUNIT_ASSERT, die Vergleiche zwischen Soll- und Ist-Werten des/der von einer Unit errechneten Werte(s) durchführen. Das Ergebnis aller Unit Tests einer TEH wird dann in der Ergebnisdarstellung von ABAP Unit präsentiert.

Ein Beispiel

Betrachten wir ein Beispiel, um diese Zusammenhänge etwas transparenter zu machen. Unsere minimalistische TEH ist ein Prozentrechner, der diese Aufgabe an ein Unterprogramm delegiert:

REPORT  Percentages.

PARAMETERS: price TYPE p.

PERFORM minus_ten_percent CHANGING price.

WRITE price.

 

FORM minus_ten_percent CHANGING fprice TYPE p.

  price = fprice * '0.9'.

ENDFORM.                    "Minus_ten_percent

 

Wir schreiben eine Testklasse in den Report, der testet, ob das Unterprogramm für einen gegebenen Grundwert den Prozentwert richtig berechnet.

 

CLASS test DEFINITION FOR TESTING.  "#AU Risk_Level Harmless
"#AU Duration Short

  PRIVATE SECTION.

    METHODS test_minus_ten_percent FOR TESTING.

ENDCLASS.                   

CLASS test IMPLEMENTATION.

  METHOD test_minus_ten_percent.

    DATA: testprice type p value 200.

    PERFORM minus_ten_percent CHANGING testprice.

    cl_aunit_assert=>assert_equals( act = testprice exp = 180

                     msg = 'ninty percent not calculated correctly').

  ENDMETHOD.                   

ENDCLASS.  

Die Testklasse und die Testmethode TEST_MINUS_TEN_PERCENT werden vom Tool durch den Zusatz FOR TESTING erkannt. Die Zusätze "#AU RISK_LEVEL HARMLESS und "#AU DURATION SHORT sind keine optionalen Kommentare, sondern so genannte Annotationen, die technisch notwendigte Informationen enthalten. Mit dem RISK_LEVEL bestimmen Sie, ob und wenn ja in welchem Maße die Durchführung des Tests kritische Daten gefährdet. Die Angabe der Zeit dient dazu, dass Tests, die sich in Endlosschleifen gefangen haben, wegen Zeitüberschreitung automatisch abgebrochen werden können.

In der Transaktion SAUNIT_CLIENT_SETUP stellen Sie für ein ganzes System ein, wie risikoreich ein Test sein darf (RISKLEVEL) und welche Zeitspanne jeweils den Attributen, die die zulässige Dauer spezifizieren, (DURATION: SHORT, MEDIUM und LONG) zugeordnet ist. Beispielsweise wollen Sie auf manchen Entwicklungssystemen keine Tests zulassen, die wichtige Daten verändern. Wenn der Test aus irgendeinem Grund abbricht, bleiben unter Umständen Daten mit falschen Werten oder in einem inkonsistenten Zustand zurück. Deswegen werden Sie in solchen Systemen den zulässigen RISKLEVEL entsprechend niedrig einstellen.

Der Service der Klasse CL_AUNIT_ASSERT

Die Servicemethode CL_AUNIT_ASSERT=>ASSERT_EQUALS benötigt als Parameter einen Erwartungswert und einen tatsächlichen Wert, der das Ergebnis der getesteten Berechnung ist, und vergleicht diese. Die Parameter MESSAGE sollte einen Satz enthalten, der beschreibt, was beim Testen misslungen ist. Weiterhin können Sie der Servicemethode CL_AUNIT_ASSERT=>ASSERT_EQUALS noch einen Parameter mitgeben, der die Schwere des Fehlers bezeichnet, und einen Parameter, der angibt, was passieren soll, falls der Test fehlschlägt: Soll die Testmethode einfach weiterlaufen, soll die gegenwärtige Testmethode, die ganze Testklasse, oder sollen alle Tests der TEH abgebrochen werden?

Neben dieser einen Methode bietet Ihnen die Klasse CL_AUNIT_ASSERT noch andere Methoden an, die unterschiedliche Überprüfungen durchführen und das Ergebnis ans Framework geben. Wichtiger als diese Details ist das Verständnis, dass Sie mit den Parametern der Methoden der Serviceklasse CL_AUNIT_ASSERT den Ablauf des gesamten Unit Tests steuern können und Informationen in die Testmethoden packen, die Ihnen später in der Ergebnisdarstellung wichtige Details über den aufgetretenen Fehler liefern.

Die Ergebnisdarstellung von ABAP Unit

In der Ergebnisdarstellung sehen Sie auf der linken Seite alle Tests Ihrer TEH zu einer Task zusammengefasst. In unserem Fall ist das nur eine Testklasse mit einer Methode:

Diese Grafik wird im zugehörigen Text erklärt 

Über den Namen der Methode können Sie auf der linken Seite in der Detaildarstellung anschauen, was im Einzelnen in der Testmethode beim Test einen Fehler verursacht hat:

 

 Diese Grafik wird im zugehörigen Text erklärt 

Oben sehen Sie die Nachricht, die Sie der Servicemethode mitgegeben haben. Darunter sehen Sie, welche Werte divergieren und über die Stack-Zeile können Sie in die Klasse navigieren.

Im Beispiel erkennen Sie beim genaueren Blick auf das Coding, dass Sie den Eingabeparameter des Reports mit dem Changeparameter des Unterprogramms verwechselt haben.

Ende des Inhaltsbereichs