ABAP Quick - Creation of test data
What challenges do you have when setting up test tables and test data and how can machine processing help you?
Table of contents
Today's tip is about creating test data easily, migrating the test application to other systems, and quickly restoring the data in the system. We take a closer look at the various options in detail.
Provide data
Are you currently setting up a new table and want to fill it directly with data? There are two ways of getting the data into the table:
- Creation of a view
- Insertion by program
Let's first set up a table. The quick and easy way is to create it using the ABAP Development Tools (ADT), since the table is defined in a simple form here. You save yourself the need to set the technical details and jump to the extension category. Our test table looks like this:
Table Maintanance view
A table maintenance view is created after the table has been created. With this you can then insert, edit and delete new data records. A function group and maintenance modules are generated, so a relatively large number of objects are required.
- Function group with modules
- Dynpros
- Includes with events
Program
Here you create an executable class or a report and fill in the data at the push of a button. Only a simple object (class, report) is required. So what could such an executable class look like?
CLASS zcl_bs_demo_fill_account DEFINITION PUBLIC FINAL CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES if_oo_adt_classrun.
PROTECTED SECTION.
PRIVATE SECTION.
ENDCLASS.
CLASS zcl_bs_demo_fill_account IMPLEMENTATION.
METHOD if_oo_adt_classrun~main.
DATA:
lt_account TYPE STANDARD TABLE OF zbs_dy_account WITH EMPTY KEY.
lt_account = VALUE #(
( identifier = '1000000010' amount = '12.34' currency = 'EUR' account_active = abap_true )
( identifier = '1000000011' amount = '200.00' currency = 'USD' account_active = abap_true )
( identifier = '1000000012' amount = '55.50' currency = 'EUR' account_active = abap_false )
( identifier = '2000000010' amount = '13.37' currency = 'CHF' account_active = abap_false )
).
DELETE FROM zbs_dy_account.
INSERT zbs_dy_account FROM TABLE @lt_account.
out->write( |Datasets inserted { sy-dbcnt }| ).
COMMIT WORK.
ENDMETHOD.
ENDCLASS.
Hint: So that the class remains executable, you should first clean up the table before inserting the data. Don't forget to call a clean commit at the end.
Compare
When comparing the two variants, the maintenance view is the most flexible, you can adapt the entries directly and copy them from Excel directly into the table. The only negative point is the large number of objects created to maintain the table. If you want to move the objects to another system, this is not possible, unless you would export the data to Excel. But here you are far from an automatic process.
- + Flexible
- - Number of objects
- - No data migration
In addition, the construct with an executable class is relatively flexible, as you can always adjust the data in the class. Here, however, you always work with the full data package when you change the data. When the objects are migrated, data content is also moved and is available again in the target system at any time.
- - Relative flexible
- + Number of objects
- + Data migration
Usage
You want to quickly show your colleague a small application and need test data for this, then the executable class is a quick and easy way to make data available and to be able to adapt it again and again without disrupting your actual development process. The creation of test data is also a popular example where you have to adjust the data again and again when you adapt your test cases. If you have written a comprehensive application, then you might want to roll it out in other systems and need the corresponding data for your ABAP unit test cases.
There are many cases in which you will need the data over and over again. The maintenance via the maintenance view will always be effective and the simplest, but rolling out the maintenance view via abapGit, for example, will put more stumbling blocks in your way than you actually need. The deinstallation of such maintenance views is currently not properly supported and in the end you will be missing the data for maintenance.
With this in mind, we recommend using the executable object if you have no other requirements, as it is the most flexible variant when transferring objects, migrating and providing data in an empty system.
Hint: Creating test data is also made more difficult in the cloud environment (steampunk), as there is no GUI and no table maintenance generator. The easiest way here is to create the data via the executable class.
Productive
Of course, you should specifically secure such data creation objects so that no one can simply execute them in the productive system accidentally. The easiest way here is probably to check the authorizations against Debug & Change, since debugging is possible in any clean production system, but Debug & Change is not. At least you should keep this point in mind when transporting such objects into production.
Conclusion
What is the easiest way to get test data into the system and transfer it to the next system? There are different approaches here and you should decide what suits you best depending on the situation.
