Our ABAP expert Alex Geppart introduces you to two open source helpers for creating test data for ABAP unit tests. Regardless of whether we use the Test First or the Test Last approach, the test data for unit tests must be prepared. Depending on the test data, this process can be very time-consuming. For this very reason, we have written two ABAP debugger extensions to solve this problem.
Just imagine that the signature of the method to be tested has a mandatory importing parameter for a table of flights. This table must contain n rows to reproduce an error in the coding. Currently, we would be forced to manually prepare every row and every field-value combination of this table to get this:
lt_flights = VALUE #(
( carrid = 'AA' fldate = '20170208' price = '422.94' currency = 'USD' )
( carrid = 'LH' fldate = '20170307' price = '431.94' currency = 'USD' )
...
The test data can often be viewed in the debugger the first time an error is debugged. However, it would be much more helpful to use an option that can export this data from the debugger in an ABAP coding-friendly way.
Features
The first extension we would like to introduce to you is for table export. The second is for structure data export, as both processes can be extremely time-consuming without an extension.
Table data export
In this step, I will show you how you can easily export the data of an internal table from the debugger. To do this, you must first switch to the "Tables" view in the debugger for internal tables. In the next step, switch to the ALV view. There you will now find the "Data for ABAP View" button.
Clicking on it opens a popup that asks for the pagination point for the generated data.
The data from the internal table is then displayed according to your specifications. You can now simply copy and paste this data.
Structure data export
The second step is to export the structure data. To do this, you need to display the structure in the debugger. Simply click on the "Structures" tab. There you can now click on "Toolservices", as marked in red in the following image, to return to the "Data for ABAP View" option.
From this step, the process continues as already described for the first extension. By clicking on "Data for ABAP View", a popup opens again, which queries the break point for the generated data. The data is then displayed according to your specifications and can be used via copy and paste.
Implementation details
We have tried to extend the debugger accordingly using a lightweight approach. In this case, lightweight means achieving the goal without modifying or copying and pasting function groups. Unfortunately, we could not find a suitable UserExit in the SAP coding of the debugger. For this reason, we decided to use the Enhancement Framework and its implicit enhancement options.
In the coding of our solution you will find the two extensions discussed for table data (extension zenh_table_values) and structure data (extension z_struc_v_build_services_menue). An ABAP class for table data (class ZCL_DEBUG_DATA_VIEW_TABLE_ENH) and structure data (class ZCL_DEBUG_DATA_VIEW_STRUC_ENH) is available for each of the two extensions.
There is also an ABAP report Z_DEBUGGER_DATA_VIEW_EXT_DEMO with which you can easily test the functionality described. All you have to do is place two breakpoints in the report and run the report. The current solution is strongly based on the classes CL_DEMO_OUTPUT and CL_DEMO_INPUT. These two classes are marked by SAP as "for demonstration purposes only" and should not be used in productive systems. Since the tests are written in development environments and run at most in test environments, no productive systems are affected.
We also plan to offer you our own ABAP screens to provide the functionality of CL_DEMO_OUTPUT and CL_DEMO_INPUT.
Prerequisites
The solution is based on the new VALUE operator. For this reason, at least ABAP version 7.40 is required. The demo ABAP report uses the DB table SFLIGHT to select the data. If this table is not filled in the system, the report cannot be used for demo purposes. In this case, the functionality can be tested with any similar procedure.
Installation
You can find all the coding here.
To import it into your system, you should use abapGit.
Pull requests and issues in GitHub are welcome.
Possible extensions to the current solution
- SUPPORT for older ABAP versions
- UI - positive list for fields to be mapped/displayed
- UI - negative list for fields that should be ignored (e.g. client)
- Replacing CL_DEMO_OUTPUT
- Eclipse plugin with similar functionality
The further development
In the first part, I introduced you to two open source helpers for creating test data for ABAP unit tests in order to simplify the preparation of test data for unit tests. Now I would like to introduce you to a few new features.
Almost a year after the publication of part 1 of my ABAP debugger extension, a lot has changed through continuous refactoring. By focusing on the single responsibility principle, the number of classes in the implementation has increased somewhat, but only for the benefit of reusability and better readability.
The next step was to adapt the actual integration into the debugging framework - whereby I had to learn a lot more about the ABAP asXML format format. This change was essential in order to retain all the data of the construct, even with complex data constructs, and thus to be able to use more than just the superficial descriptions. Only when all data is available is it possible to jump between the structure and internal table formatting and vice versa. But more on this in the last section.
One of my major goals was to decouple the formatting of the Value # construct from the syntactically correct formatting of the construct by adding breaks and spaces. However, this formatting led me to the limits of the ABAP RegEx possibilities, as the lack of support for look-behind in ABAP (or in POSIX) meant that formatting exclusively via RegEx was not possible. For these reasons, I quickly discarded this approach. An alternative had to be found, but I quickly found it in the functions of the CL_ABAP_STRING_C_READER class.
For the user of my ABAP debugger extension, an important function has also changed. In the new version, there is no longer a query about the maximum length of the line. At this point, an extension option is now offered to write your own pretty-printer implementations. This requires a new class to implement the interface ZIF_OP_VALUE_PRETTY_PRINTER. Furthermore, this class should be assigned to a user via transaction SM30 in the table ZTOP_DVE_CUST (see Figure 1). In the standard case, the supplied class ZCL_OP_VALUE_PRETTY_PRINTER is automatically used for formatting.
Another key improvement concerns the display of complex data constructs (itab in itab, itab in structure, etc.), as already mentioned above. Thanks to the new integration using asXML, I have now also been able to display these constructs. This means that in addition to the already available options for displaying structures and tables individually, the following additional options are now also available.
Now you can get back to work. You can find the latest version of the coding here. As always, this can be transferred to your own SAP system via ABAPGit. If you have any problems or questions about the new version of the ABAP debugger extension, you are welcome to open a new issue here.
