This is a test message to test the length of the message box.
Login
ABAP Unit TDF CDS Double
Erstellt von Software-Heroes

ABAP Unit - TDF (CDS Double)

In diesem Artikel geht es um den Test von Core Data Services und wie die du die Test Doubles mit Hilfe des TDF ausschalten kannst.

Werbung

Das Test Double Framework (kurz TDF) stellt Werkzeuge zur Verfügung um für die Objekte Klasse, Tabelle und Core Data Service (CDS) zur Testlaufzeit sogenannte Doubles zu erzeugen und gegen sie zu Testen. Diese Technik soll Abhängigkeiten zu schwer testbaren Objekten reduzieren und sich auf den Test der eigentlichen Komponente (Klasse) fokussieren.

 

Allgemein

Beim CDS Double verhält es sich so ähnlich wie bei dem SQL Double, wir tauschen die Daten zur Testlaufzeit in den entsprechenden Tabellen oder Entitäten aus, um unseren Test durchführen zu können. Dazu als Beispiel einmal eine Hierarchie von Views und Tabellen.

 

Um die oberste View und die Views darunter zu testen, stehen uns zwei verschiedene Testvarianten zur Verfügung:

  • Test des CDS Views (2) - Wir tauschen die direkten Zugriffe zum CDS View aus, egal ob Tabelle oder anderer CDS View und testen die Funktionalität der View für sich. Funktionieren alle Aggregationen und Calculated Fields, werden die Daten korrekt zugeordnet.

 

  • Hierarchie Test (3) - Wir tauschen Tabellen und andere CDS Views an beliebigen Stellen der Hierarchie aus und testen die Datenverarbeitung innerhalb der View Hierarchie, sowie die Verarbeitung der Daten bis hin zum Testview. Je nach Breite der Hierarchie kann das entsprechend aufwändig sein.

 

Beispiel

Als Beispiel haben wir auf die Tabelle mit den Werkzeugen und Texten jeweils einen CDS View als Interface gesetzt und diese als Consumption View mit etwas Zusatz-Logik publiziert. Hier einmal die Definition der finalen View.

 

Dabei sieht die Hierarchie der Views und Tabellen wie folgt über den SQL Dependency Graph aus (an oberster Stelle der Consumption View, in der Mitte die Interface-Views und unten die beiden Datenbanktabellen):

 

Das Ergebnis anhand der vorhandenen Daten in der Datenbank sehen wie folgt aus. Zu beachten ist, dass die Feldnamen für die Ausgabe normalisiert wurden.

 

Da wir für den CDS View keine verarbeitende Klasse haben, legen wir eine globale Klasse an, die wir als FOR TESTING kennzeichnen. Damit ist die Klasse nicht verwendbar, enthält aber unsere gesamten Testfälle für den Core Data Service.

CLASS zcl_bs_demo_double_cds DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC
  FOR TESTING.

  PUBLIC SECTION.
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zcl_bs_demo_double_cds IMPLEMENTATION.
ENDCLASS.

 

Dazu nun die entsprechende Testklasse mit der Implementierung von drei Testmethoden zur Prüfung von:

  • Ermittlung des Gesamtwerts
  • Vollständigkeit der Testdaten
  • Leerer Text bei fehlender Sprache

 

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.


CLASS ltc_cds_access IMPLEMENTATION.
  METHOD class_setup.
    DATA:
      lt_table_tools TYPE STANDARD TABLE OF zbs_dy_tools WITH EMPTY KEY,
      lt_cds_texts   TYPE STANDARD TABLE OF zbs_i_tooltexts WITH EMPTY KEY.

    go_environment = cl_cds_test_environment=>create(
      i_for_entity = 'ZBS_C_COMPLETETOOLS'
      i_dependency_list = VALUE #(
        ( name = 'zbs_dy_tools' type ='TABLE' )
        ( name = 'zbs_i_tooltexts' type ='CDS_VIEW' ) )
      ).

    lt_table_tools = VALUE #(
      ( short_name = 'NAILS' stock_quantity = 2 price = '15.00' )
      ( short_name = 'WRENCH' stock_quantity = 10 price = '17.99' )
    ).
    go_environment->insert_test_data( i_data =  lt_table_tools ).

    lt_cds_texts = VALUE #(
      ( ShortName = 'NAILS' Language = 'E' Description = 'Example text' )
      ( ShortName = 'WRENCH' Language = 'D' Description = 'No text' )
    ).
    go_environment->insert_test_data( i_data =  lt_cds_texts ).
  ENDMETHOD.


  METHOD class_teardown.
    go_environment->destroy( ).
  ENDMETHOD.


  METHOD totalvalue_calculation.
    SELECT SINGLE *
      FROM zbs_c_completetools
      WHERE ShortName = 'NAILS'
      INTO @DATA(ls_result).

    cl_abap_unit_assert=>assert_equals( act = ls_result-TotalValue exp = '30.00' ).
  ENDMETHOD.


  METHOD missing_text.
    SELECT SINGLE *
      FROM zbs_c_completetools
      WHERE ShortName = 'WRENCH'
      INTO @DATA(ls_result).

    cl_abap_unit_assert=>assert_initial( ls_result-Description ).
  ENDMETHOD.


  METHOD dataset_count.
    SELECT *
      FROM zbs_c_completetools
      INTO TABLE @DATA(lt_result).

    cl_abap_unit_assert=>assert_equals( act = lines( lt_result ) exp = 2 ).
  ENDMETHOD.
ENDCLASS.

 

Aufbau der Testdaten geht in einem Schritt für einen CDS View und für eine Datenbanktabelle, was den Austausch innerhalb einer ganzen Hierarchie vereinfacht. Die Trennung zu den echten Daten kann auf verschiedenen Ebenen erfolgen, je nachdem was man testen möchte.

 

Ablauf

Der Ablauf der Tests gestaltet sich wie beim SQL Double und sieht deshalb die folgenden Schritte vor:

  • Vorbereitung der Testdaten in der Methode CLASS_SETUP
  • Übergabe der Testdaten an das Environment
  • Durchführung der Testfälle
  • Abbau des Environment in der Methode CLASS_TEARDOWN

 

Anlage Eclipse

In Eclipse gibt es für die Anlage einer Testklasse für Core Data Services einen Wizard der zur Verfügung gestellt wird. Dieser Wizard legt eine globale Testklasse an und erzeugt Beispiel Zugriffe auf die Daten und stellt ein Environment mit Testdaten zur Verfügung. Dazu legen wir für unseren Consumption View eine Testklasse an. 

Dazu im Navigationsbaum auf den CDS View Rechtsklick und Auswahl des Kontextmenü-Eintrags für eine neue ABAP Testklasse.

 

Im nächsten Schritt legst du den Namen der globalen Testklasse und die Bezeichnung fest. Gegebenenfalls kannst du auch noch das Paket ändern, wenn die Testklasse in einem anderen Paket untergebracht werden soll.

 

Als Nächstes musst du die Art des Tests auswählen, hier hast du die Möglichkeit eines einfachen Unit Tests des CDS Views oder einem Hierarchie Test.

 

Als Nächstes folgen die entsprechenden Testdaten, die man bereits hier vorbelegen kann. Für jede Entität, die man austauscht, kann man entsprechende Datensätze vorbelegen.

 

Nach Befüllung der Daten und einem Klick auf “Finish” wird die entsprechend gewählte Testklasse angelegt, die erste Testmethode implementiert und die Befüllung der Daten übernommen. Ab hier kannst du weitere Methoden oder Daten hinterlegen.

 

Fazit

Um COre Data Services testen zu können, musst du im ersten Schritt eine globale Testklasse für die Objekte anlegen und kannst dann deine Testfälle implementieren. Der Test mit Daten funktioniert ähnlich wie beim SQL Double.


Enthaltene Themen:
ABAP UnitABAPUnit TestsTest-Double-FrameworkCDS Double
Kommentare (0)

ABAP Unit - Tipps

Kategorie - ABAP

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.

12.11.2021

ABAP Unit - Software-Architektur

Kategorie - ABAP

Wie könnte die Ziel Architektur in einem SAP System aussehen, wenn wir uns die eigenen Software Komponenten anschauen? Dies wollen wir in diesem Artikel klären.

05.11.2021

ABAP Unit - Testbarer Code (Teil 3)

Kategorie - ABAP

Hier schauen wir uns die Möglichkeiten etwas genauer an, wie man abhängige Komponenten im eigenen Coding zur Testlaufzeit deaktivieren können.

29.10.2021

ABAP Unit - Testbarer Code (Teil 2)

Kategorie - ABAP

In diesem Artikel geht es um das Thema Test Isolation und wie es unseren Code testbarer macht.

22.10.2021

ABAP Unit - Testbarer Code (Teil 1)

Kategorie - ABAP

In diesem Artikel schauen wir uns an, wie du auch in älterem Code sauber neue Funktionen implementieren und du diese im Anschluss auch testen kannst.

08.10.2021