Testdaten für ABAP Unit direkt aus dem Debugger: DDVE-Update mit typisierten VALUE-Anweisungen

· Alex Geppart

*Diesen Artikel gibt es auch auf Englisch bei LinkedIn.

Der Debugger zeigt einem oft genau die Daten, die man für einen Unit-Test bräuchte – und dann tippt man sie von Hand ab. DDVE (Debugger Data View Extension) spart euch diesen Schritt: ein Klick, und ihr bekommt eine fertige VALUE-Anweisung zum Einfügen. Das jüngste Update erzeugt diese Anweisung typisiert und schließt ein paar alte Lücken – und seit meinem letzten Blogpost 2019 hat auch die Community einiges beigetragen.

So funktioniert’s

DDVE ergänzt den Debugger an drei Stellen um den Eintrag „Data for ABAP View“: in den Service-Menüs des Tabellen- und des Struktur-Werkzeugs und in der Toolbar der ALV-Anzeige einer Tabelle. Heraus kommt eine syntaktisch korrekte, formatierte Anweisung wie diese, die ihr direkt in eure Testmethode kopieren könnt:

DATA(ls_request_header_data) = VALUE grac_s_ws_api_reqhdr(
         reqtype  = '002'
         priority = '001'
         ).
Der neue Eintrag „Data for Abap View“ im Service-Menü der Tabellenanzeige
Der neue Eintrag „Data for Abap View“ im Service-Menü der Tabellenanzeige
Das Ergebnis-Popup mit der erzeugten VALUE-Anweisung
Das Ergebnis-Popup mit der erzeugten VALUE-Anweisung

Unter der Haube

DDVE klinkt sich über drei implizite Enhancements in den Standard-Debugger ein – ohne Modifikation. Alle drei übergeben an dieselbe Pipeline: echte Daten lesen, Typ auflösen, VALUE-Anweisung rendern, formatieren und anzeigen.

Architekturübersicht: drei implizite Enhancements im Standard-ABAP-Debugger übergeben an die DDVE-Pipeline
Architekturübersicht: drei implizite Enhancements im Standard-ABAP-Debugger übergeben an die DDVE-Pipeline

Neuer Name, neues Zuhause

Vielleicht kennt ihr das Tool aus meinen SAP-Community-Posts von 2017 und 2019. Seitdem habe ich es überarbeitet, erweitert und umbenannt, und es liegt jetzt in einem neuen GitHub-Repository:

https://github.com/gepparta/abap_debugger_data_view_extension

Gefreut habe ich mich, DDVE im DSAG-ABAP-Leitfaden wiederzufinden: Dort ist es als SAP-GUI-Variante genannt, um VALUE-Anweisungen aus Debugger-Daten zu erzeugen.

Alle Klassen folgen jetzt dem Namensschema ZCL_DDVE_*. Neu in diesem Update:

  1. Typisierte VALUE-Anweisungen mit Inline-Deklaration – DATA(flights) = VALUE flighttab( ... ) statt eines untypisierten #
  2. Robustheits-Fixes für verschachtelte Daten in gefilterten Exporten, anonyme Laufzeittypen sowie leere Tabellen und Strukturen
  3. Ein überarbeiteter Kern mit deutlich mehr Unit-Tests

Seit 2019 hat die Community außerdem einen ALV-Export beigetragen, der Filter, ausgeblendete Spalten und Sortierung berücksichtigt, dazu .INCLUDE-Unterstützung und Fixes für Hashed Tables – mehr dazu weiter unten.

Neu in diesem Update

1. Typisierte VALUE-Anweisungen mit Inline-Deklaration

Bisher sah die erzeugte Anweisung so aus: lt_flights = VALUE #( ... ). Das funktioniert, solange die Zielvariable schon existiert und der Compiler den Typ ableiten kann. In einem frischen Unit-Test kann er das meist nicht.

Typisierte Anweisungen waren ein alter Feature-Wunsch von Timo John – jetzt sind sie da. DDVE ermittelt den Typ der Variablen aus dem Debugger-Kontext und erzeugt eine eigenständige Inline-Deklaration:

" DDIC type
DATA(table_of_flights) = VALUE flighttab( ( carrid = 'AA' connid = '0017' ) ).

" type declared inside a global class
DATA(item) = VALUE zcl_order=>ty_item( col1 = 1 ).

Spannend ist die Frage, welcher Typname überhaupt verwendbar ist. Der Debugger liefert absolute Typnamen wie \CLASS=ZCL_ORDER\TYPE=TY_ITEM oder \PROGRAM=ZREP\TYPE=TY_LOCAL. Lässt sich kein verwendbarer Typ- oder Variablenname ableiten – etwa bei einem Komponentenpfad wie LS_X-COMP –, fällt DDVE auf die klassische untypisierte Form VALUE #( ... ) zurück, denn DATA(...) mit # würde nicht kompilieren. Die neue Klasse ZCL_DDVE_TYPE_RESOLVER übersetzt die Typnamen des Debuggers in Ausdrücke, die im Quellcode gültig sind:

Typname im DebuggerErzeugter AusdruckWarum es im Test funktioniert
\TYPE=SFLIGHTsflightDDIC, überall sichtbar
\CLASS=ZCL_X\TYPE=TY_Yzcl_x=>ty_ypublic immer, private über LOCAL FRIENDS
\INTERFACE=ZIF_X\TYPE=TY_Yzif_x=>ty_yInterface-Komponenten sind public
\PROGRAM=ZREP\TYPE=TY_LOCALty_localTest-Include liegt im selben Programm
\TYPE-POOL=ABAP\TYPE=ABAP_BOOLabap_boolTypgruppen sind global
prozedurlokale / generierte TypenRückfall auf #aus einem Test nicht adressierbar

2. Robustheits-Fixes für knifflige Fälle

Ein paar alte Randfälle sind erledigt:

  • Verschachtelte Daten in gefilterten Exporten – seit der Filter-Unterstützung von 2023 (siehe Community-Abschnitt unten) landeten verschachtelte Tabellen und Strukturen im ALV-Export als Platzhaltertexte wie COL2 = `Structure: flat, not charlike` . Arbeitet das ALV des Debuggers auf einer internen Kopie der Tabelle, liest DDVE jetzt die echten Daten nach und nutzt die ALV-Ansicht nur noch als Zeilen- und Spaltenmaske – Filter, ausgeblendete Spalten und Sortierung gelten weiter, und verschachtelte Daten behalten ihre echten Werte.
  • Anonyme Laufzeittypen – inline deklarierte Tabellentypen, OCCURS-Kopfzeilen, TYPE HANDLE-Strukturen – werden jetzt aus den Metadaten des Debuggers rekonstruiert, statt still gar kein Ausgabe-Popup zu erzeugen.
  • Leere Tabellen und Strukturen ergeben eine gültige leere VALUE-Anweisung statt kaputter Ausgabe.

3. Ein überarbeiteter Kern mit mehr Tests

Schon der Post von 2019 ging auf Single Responsibility ein, diese Runde geht weiter. Das Rendern der VALUE-Ausdrücke liegt jetzt in einer eigenen Klasse (ZCL_DDVE_VALUE_RENDERER), die die komplette Rekursion für verschachtelte Daten übernimmt, während die Debugger-Fassaden für Tabellen und Strukturen nur noch orchestrieren. Ausgabe (CL_DEMO_OUTPUT), Customizing-Zugriff und die Erzeugung des Pretty Printers stecken hinter eigenen kleinen Klassen – genau deshalb bringt das Paket jetzt eine deutlich breitere ABAP-Unit-Testsuite mit, größtenteils ohne Mocks.

Seit 2019: Beiträge aus der Community

Zwischen 2020 und 2023 sind mehrere Pull Requests ins Tool eingeflossen, ohne je einen eigenen Blogpost zu bekommen. Wer noch die Version von 2019 nutzt, für den sind sie ebenfalls neu.

What you see is what you get

Dank @WegnerDan berücksichtigt der Export, was ihr im ALV des Debuggers seht:

  • Im ALV ausgefilterte Zeilen fehlen in der erzeugten Anweisung.
  • Im ALV-Layout ausgeblendete Spalten (no_out) werden übersprungen.
  • Der Export folgt der aktuellen Sortierung im ALV.
  • Die technische INDEX-Spalte des ALV landet nicht mehr in der erzeugten Anweisung.

So könnt ihr eure Testdaten vor dem Export im ALV zurechtformen – eine erstaunlich wirksame Methode, um eine Produktivtabelle mit 500 Zeilen auf die drei Zeilen einzudampfen, die euren Bug wirklich reproduzieren.

Weitere Beiträge

  • .INCLUDE-Strukturen – @juancarlosrodriguezf hat dafür gesorgt, dass Strukturen mit .INCLUDEs (etwa ein lokaler Typ, der T000 plus weitere Felder einbindet) korrekt in den Feldkatalog aufgelöst werden. Vorher gingen die eingebundenen Komponenten verloren, der Fix bringt einen eigenen Unit-Test mit.
  • Hashed Tables und Performance – @sandraros hat die Generierung beschleunigt und Fixes für Hashed Tables sowie für Tabellen mit einer Komponente namens INDEX beigesteuert.
  • Pretty Printer und Pflege – @andkopp hat Details im Pretty Printer korrigiert, und @christianguenter2 hat das Repository auf das aktuelle abapGit-Format gebracht und einen Syntaxfehler behoben.

Danke an alle, die beigetragen haben!

Eine Anmerkung zum eingebauten Pretty Printer

Der Post von 2019 hat das Pretty Printing der erzeugten VALUE-Anweisung ziemlich in den Vordergrund gestellt – inklusive der Möglichkeit, über ein Pretty-Printer-Interface (heute ZIF_DDVE_VALUE_PRETTY_PRINTER) und die Customizing-Tabelle ZTOP_DVE_CUST eine eigene Implementierung einzuhängen.

Ehrlich gesagt ist dieser Teil unwichtiger geworden: Mit dem ABAP Cleaner gibt es inzwischen einen hervorragenden Open-Source-Formatierer, der VALUE-Konstruktorausdrücke in ADT sauber ausrichtet. Ein völlig legitimer Ablauf ist heute also: die rohe Anweisung mit DDVE exportieren, in die Testmethode einfügen und die Formatierung dem ABAP Cleaner überlassen.

Die eingebauten Pretty Printer und der Customizing-Mechanismus sind weiterhin da und nützlich, wenn ihr direkt im SAP-GUI-Popup eine lesbare Vorschau wollt. Wer mit ADT und ABAP Cleaner arbeitet, muss sich um dieses Feature aber keine großen Gedanken machen.

Umstieg von der alten Installation

Wer noch die Originalversion mit den ZCL_OP_*-Klassen im Einsatz hat: Die Enhancement-Implementierungen und die Customizing-Tabelle heißen in beiden Versionen gleich. Deshalb:

  1. Exportiert eure Einträge in ZTOP_DVE_CUST (falls vorhanden).
  2. Deinstalliert das alte Paket über abapGit (Uninstall/Purge).
  3. Zieht das DDVE-Repository.
  4. Importiert euer Customizing wieder und ersetzt die Klassennamen: ZCL_OP_VALUE_PRETTY_PRINTER → ZCL_DDVE_VALUE_PRETTY_PRINTER, ZCL_MAX_LINE_LENGTH_PP → ZCL_DDVE_MAX_LINE_LENGTH_PP.

Installiert die beiden Versionen nicht parallel.

Voraussetzungen

NetWeaver ABAP 7.40 SP08 oder höher.

Installation

Der komplette Code liegt hier:

https://github.com/gepparta/abap_debugger_data_view_extension

Bitte nutzt abapGit, um den Code in euer System zu holen. Pull Requests und Issues auf GitHub sind willkommen.

Fragen zu Ihrem Custom Code?

Im Erstgespräch schauen wir gemeinsam auf Ihre Situation – unverbindlich und ohne Folien-Schlacht.