ABAP Unit - Tipps
Zum Abschluss der Serie noch ein paar Tipps die wir dir mit auf den Weg geben wollen. Hier geht es um Shortcuts und allgemeine Hinweise zu den Tests.
Inhaltsverzeichnis
Für das Schreiben von testbarem Code und die Navigation unter den Testobjekten werden in diesem Artikel noch einige Tipps und Tricks aufgezeigt zur besseren Handhabung der Testfälle.
Verlinkung
Wie du bereits im Artikel mit den CDS Double gesehen hast, wird für das Objekt eine eigene Klasse angelegt und als Testklasse gekennzeichnet. Dieses Objekt ist aber nicht mit dem Core Data Service verbunden und wird nicht zusammen mit dem Objekt getestet. Zum Test des Objekts muss das gesamte Paket getestet werden.
Bei der Ausführung des Tests auf dem Objekt kommt es zur folgenden Meldung:
Für diesen Umstand kann der Testklasse mitgeteilt werden, welches Objekt aktuell getestet wird und was die abhängigen Objekte sind. Dazu greifen wir auf ABAP Doc zurück und hinterlegen damit unser Objekt an der Testklasse. Dazu der geänderte Code der Testklassen-Definition:
"! @testing ZBS_C_COMPLETETOOLS
CLASS ltc_cds_access DEFINITION FINAL FOR TESTING
DURATION SHORT
RISK LEVEL HARMLESS.
PRIVATE SECTION.
CLASS-DATA:
go_environment TYPE REF TO if_cds_test_environment.
CLASS-METHODS:
class_setup RAISING cx_static_check,
class_teardown.
METHODS:
totalvalue_calculation FOR TESTING,
missing_text FOR TESTING,
dataset_count FOR TESTING.
ENDCLASS.
Der ABAP Doc Kommentar mit @testing und dem Objekt (Großschreibung beachten) folgend muss hinzugefügt werden. Die Testklasse ist nun mit dem Core Data Service verbunden und wenn du den Unit Test direkt für diesen ausführst, erhältst du ein Ergebnis.
Der Test wird als “Foreign Test” angezeigt, da dieser sich nicht direkt am Objekt befindet. Du hast an dieser Stelle auch die Möglichkeit einzelne Methoden zu kennzeichnen, wenn du in einer Testklasse verschiedene Objekte testest. Theoretisch kann dann jede Methode mit einem anderen Objekt verknüpft sein. Wir empfehlen dir aber eine Testklasse pro Objekt anzulegen, um so die Tests sauber voneinander zu trennen.
Eclipse Shortcuts
Für ein effizienteres Arbeiten in Eclipse mit Unit Tests und die schnellere Ausführung der Tests während der Entwicklung, empfehlen wir dir die Verwendung der Shortcuts. Diese sind leicht zu merken und erhöhen dein Tempo bei der Entwicklung. Shortcuts können in Eclipse im aktuellen Objekt aufgerufen werden, dann werden nur Tests dieses Objekts berücksichtigt oder du verwendest sie im Project Explorer und kann damit auch über Pakete testen.
Vorschau
Die Vorschau wird mit STRG + SHIFT + F9 gestartet und führt im ersten Schritt keinen Unit Test aus, sondern untersucht die Objekte nach ausführbaren Tests und zeigt diese an. Als Beispiel haben wir den Preview einmal für ein ganzes Paket ausgeführt.
Es werden die Objekte mit den entsprechenden Testklassen und Testmethoden angezeigt. Mit einem Rechts-Klick auf die verschiedenen Knoten hast du die Möglichkeit einzelne oder alle Tests zu starten. Hierbei kannst du auch auf die verschiedenen Methoden (Abdeckung und Trace) zurückgreifen.
Ausführung
Benötigst du keine Vorschau, dann kannst du direkt alle Tests des Objekts oder des Pakets mit STRG + SHIFT + F10 starten. Die Ausführung wird gestartet und das Testergebnis angezeigt.
Abdeckung
Mit STRG + SHIFT + F11 startest du den Unit Test mit Abdeckungsmessung und kannst so prüfen, wieviel deines Quellcodes bereits mit Testfällen abgedeckt ist. Diese Form der Ausführung dauert aber etwas länger, als ein einfacher Unit Test.
Einstellung
Bevor überhaupt eine Funktion gestartet wird, hast du mit STRG + SHIFT + F12 die Möglichkeit deine Einstellungen vor dem Start festzulegen. Du kannst die verschiedenen Einstellungen über das Popup bestimmen und hast im Anschluss die Möglichkeit die Vorschau oder die Ausführung zu wählen.
Namenskonventionen
Bei der Benennung der Testklassen und Objekte sind ja bereits auf einige Spezialitäten eingegangen. An dieser Stelle wollen wir noch Vorschläge mitgeben, wie die einzelnen Testobjekte heißen können:
- LCL_ - Lokale Klasse/Hilfsklasse
- LTC_ - Lokale Testklasse die die Testfälle enthält
- LTD_ - Lokales Test Double das du für deine Testfälle benötigst
Die Abgrenzung der verschiedenen Klassennamen macht noch einmal die Verwendung deutlich und erhöht die Lesbarkeit für andere Kollegen, da sie sofort die Unterschiede der einzelnen Objekte erkennen und was deren Zweck ist.
Schlüsselthemen
Beim Entwickeln deiner Anwendung solltest du die folgenden Themen beachten und in deinen Quellcode integrieren und/oder bereitstellen.
Konstruktor
- Nicht im Konstruktor arbeiten
- DOCs über Factory oder Lazy Initialization erzeugen
- Bereitstellung von Injection Mechanismen für deine Klasse
- Öffentliche Schnittstelle über Interfaces bereitstellen
Ein Beispiel für eine Lazy Initialization könnte wie folgt aussehen:
CLASS zcl_bs_demo_double_class DEFINITION PUBLIC FINAL CREATE PUBLIC.
PUBLIC SECTION.
DATA:
mo_uicomponent TYPE REF TO zif_test_display.
METHODS:
select_and_show_data
IMPORTING
id_short_name TYPE zbs_dy_tools-short_name
RETURNING VALUE(rd_displayed) TYPE abap_bool.
PROTECTED SECTION.
PRIVATE SECTION.
ENDCLASS.
CLASS zcl_bs_demo_double_class IMPLEMENTATION.
METHOD select_and_show_data.
SELECT *
FROM zbs_dy_tools
WHERE short_name = @id_short_name
INTO TABLE @DATA(lt_found_tools).
IF mo_uicomponent IS NOT BOUND.
mo_uicomponent = NEW zcl_test_display( ).
ENDIF.
rd_displayed = mo_uicomponent->display_generic_data( lt_found_tools ).
ENDMETHOD.
ENDCLASS.
Du erzeugst die Instanz der Komponente erst dann, wenn du darauf zugreifen möchtest. Damit hast du auch die Möglichkeit den Injection Mechanismus anzuwenden und so dein Test Double zu übergeben und zu verwenden.
Statisch und globaler Status
- Abhängigkeiten zu globalen Daten, Variablen und Objekten minimieren
- Kapselung der Daten in der Klasse
- Nutzung des Test Double Frameworks
- Objekte verwenden, anstatt statische Klassen
SOLID
- Anwendung des SOLID Prinzips bei der Entwicklung der Software
- Mehr Informationen zu SOLID auf Wikipedia
Law of Demeter
- Abhängigkeiten unter den Objekten geringhalten
- Einschränkung der Verkettungen und Abhängigkeiten unter den Objekten
Hinweis: Einige der beschriebenen Methoden sind Standard-Vorgehensweisen in der Software Entwicklung und werden im Zuge dieses Buches nicht mehr beschrieben. Weitere Informationen dazu erhältst du zum Beispiel über Wikipedia und kannst dort weitere Details dazu erfahren.
Fazit
Mit diesem Artikel endet unsere Serie zum Thema ABAP Unit und wie du es effektiv und einfach bei dir einsetzen kannst. Es gab viel Input zum Thema Testbarkeit von Anwendungen und der Architektur, denn die meisten Quellcodes sind noch nicht für die einfache Testbarkeit bereit und müssen angepasst werden. Wenn du das ganze Thema auf einen Schlag vertiefen willst, empfehlen wir dir auch das komplette Buch.