ABAP Cloud - Test Data Container

Table of contents

• Introduction
• Architecture
• Maintenance
• Usage
• Configuration
• Container
• Data
• Examples
• GitHub
• Conclusion

In this article, we want to introduce you to the open source project for test data containers. We will discuss their structure and use, and show you other possibilities. The idea arose in a discussion with Frank Engert.

 

Introduction

Test data containers are used for testing in the SAP system. This allows you to easily store and maintain generic data without having to adapt the actual unit test later. If you'd like to learn more about the classic usage, there's an article in the SAP Community. However, the containers have not been released for ABAP Cloud because there is no suitable front end for maintaining the data. Currently, all test data would have to be maintained in the test case, which makes it somewhat cumbersome and confusing.

 

Architecture

The architecture of the component is kept relatively simple, and we reuse some standards. The idea is to use an external editor to maintain the data in structured formats and to utilize the formatting options available in those editors. For example, GitHub's JSON editor takes over the validation and formatting of the content, similar to the maintenance in the SAP GUI. We can then retrieve the file from GitHub via the HTTP protocol and use it in our tests. The formats JSON, abapXML, and RAW are currently supported.

 

 

Hint: Currently, only ABAP Cloud in the public cloud is supported, as we use the new HTTP Client to establish an internet connection.

 

Maintenance

Data maintenance takes place outside of ABAP. In this example, we use the integrated IDE in GitHub to maintain the data. In the example, for example, a comma is missing; the editor highlights the corresponding location so that we receive support in maintaining the data and provide a correct format.

 

Usage

In this chapter, we will look at its use for unit tests and within the logic. To read the data, we use the 

 

Configuration

A configuration represents an access path and the reading routine for it. Currently, there is only the configuration for GitHub; you can find this in the class ZCL_TDC_GITHUB_CONFIG. We create a new configuration by passing the path to the file to the constructor.

DATA(configuration) = NEW zcl_tdc_github_config( test_file_path ).

 

The path to the raw file is required to load the file. If you view the file on GitHub, there is a button in the right corner that loads the file in the appropriate view. We will use this path as the source for the configuration.

 

Container

In the next step, we create a container to access the file. To do this, we pass the configuration to the factory method and receive the container back for use.

DATA(container) = zcl_test_container_factory=>create( configuration ).

 

The container offers us various methods for accessing the data. There are two methods for obtaining the file contents in RAW format: as a string or as an XString. Using the other two methods, we can populate our table or structure; the corresponding parsers are included in the methods.

 

Data

If we now want to load the data, we need a structure or table to which we can map the data. To do this, we define a local type that has the same format as the JSON file.

TYPES: BEGIN OF github_test,
         text    TYPE string,
         number  TYPE i,
         boolean TYPE abap_bool,
       END OF github_test.
TYPES github_tests TYPE STANDARD TABLE OF github_test WITH EMPTY KEY.

 

To read the data and fill it into the structure, we just need to call the corresponding method. In this case, we read the data as JSON. In the background, the HTTP client is used to load the data live from GitHub.

container->get_json_data( CHANGING generic = result ).

 

Examples

You can find further examples of using the test data container in the unit tests of the class ZCL_TEST_CONTAINER. All methods are used there with examples from the repository and you can find further information on creating the structure.

 

GitHub

You can find the complete open source project for the test data container in our GitHub repository. You can use the project freely.

 

Conclusion

You can use this small framework to manage complex data via an external platform and utilize the capabilities of other editors for maintenance. However, you generally have a dependency on the component, for example, if the internet is down. Ultimately, however, you can also use the container to make data available for processing, as the framework is not limited to unit tests.