Automating OData Service Testing with the eCATT OData Assistant

[melanie_reinwarth]

You can easily create automated OData integration tests with the help of the eCATT OData Assistant (transaction SECATT_ODATA).

Prerequisite

SECATT_ODATA is available in software component SAP_BASIS release 7.40, 7.41 and 7.60.

It is recommended to use the highest possible support package, since the tool is in a process of continuous improvement and completion.

Technical Background

For information on the technical landsape of the automated OData Service testing, click here.

eCATT OData Assistant Step by Step

The eCATT OData Assistant leads you through three major steps:

1. Load and Analyze Service:  In this step, service meta data is loaded from the server.
2. Create Access Class(es) for Service: In this step, access classes are generated in ABAP to enable eCATT OData testing.
3. Create Tests: In this step, the tests are created on basis of the newly created classes.

1. Load and Analyze Service

The eCATT OData Assistant (transaction SECATT_ODATA) starts with following screen (click to enlarge the picture):

To load the service meta data, proceed as follows:

1. Choose the addressing method and enter all relevant address data to retrieve service metadata.
   Depending on your scenario, different address methods can be useful:
   Using System data or local system is recommended, because these can handle more easily user credentials in a safe manner and avoid manual logon activities in the following steps.
   When using an URI, you might have to enter user credentials depending on your service provider setup.
2. Choose Load Service to retrieve the service meta data document. Once the meta data has been retrieved correctly, you find a naming proposal in the field Default Name. This name can be changed and is used as name basis for all objects to be generated later on. In addition, the Continue button is now active.

If you want to display the meta data, choose Display Service. The xml service meta data will be displayed.

Choose the Continue button or the Create Access Classes for Service step in the step path to proceed to the next step.

2. Create Access Classes for Service

2.1 User Input

The screen of this step displays the name of the main class and the corresponding service entities (sub-classes) arranged in a tree structure.

For each entity set, you can see its properties and available CRUD-operations (create, retrieve, update, delete). For each property and its datatype in EDM model, the screen shows the associated ABAP data type.

On the level of entity container, you find functions and actions provided by the service.

To generate the desired access class(es), proceed as follows:

1. If necessary, change the class name prefix. This prefix will be shared by all generated classes. A click on a class name link in the tree provides the option to change the sub-class name. In addition, you can change the class descriptions by clicking the corresponding link in the tree.
2. Choose the entity set(s) which you want to create ABAP classes for and the corresponding operations (retrieve, insert, update, delete). By default, all entity sets and all of their operations are selected.
3. Choose Generate to create the OData service access classes. The assistant will warn, if the generation process would overwrite existing classes leaving you the choice to proceed or cancel. The assistant can only overwrite such classes, which have initially been created by the assistant itself and not been modified by any other user.

2.2 Generated Access Classes

The log window in the lower part of the screen informs you about status and success of the generation process. It is a business application log, which is stored permanently in the system and can be accessed choosing Goto -> Application log -> Select and Display.

Each class name node in the tree provides a context menu option to navigate to the generated class in transaction SE80.

The class contains methods for calling CRUD operations on entities and class-based type definitions for EntityTypes, ComplexTypes and key structures.
These ABAP types allow access to the service data in ABAP variables, which are considered useful for building integration tests in ABAP coding or eCATT test scripts.

Choose the Continue button or the Create Tests step in the step path to proceed to the next step.

3. Create Tests

3.1 User Input

The Create Tests screen provides options to create test data containers and global ABAP classes containing ABAP unit test methods as test implementation.

Generated test classes will use the Service Access Classes to call the service.

You can choose names, package assignment and the transport request number. You may change test class names, test class description, test data container names (TDC) and TDC description by either clicking on it in the tree or choosing the correspondig option from context menu.

The use of test data in TDCs is optional. You can simply deselect TDCs if not required.

The creation of test classes is based on a template which includes test methods for:

1. availability checks on service metadata and on CRUD services for each EntityType
2. comparison of results of CRUD services for each EntityType against test data from generated TDC

The creation of test classes is flexible and creates only test methods for those CRUD operations, which have been selected during the creation of the service access class.

To enhance performance, you can also enter a value in the Entries field or via Test Scope -> Maximum Number of Data Sets. The value stands for the maximum number of data sets to be read. If you enter 0 or no value, all data is read.

Use Generate to create the test classes and TDCs. On the screen then displayed, again the application log is filled with the class generation status and related messages.

3.2. Use of Test Data

The generated unit tests can make use of the test data container. Test data will serve as reference data in retrieve scenarios and will be used as data templates for create scenarios.
The TDCs will contain a parameter for the assigned entity set. The parameter is typed to the ABAP structure which is related to the entity set. Remember that these ABAP structures are part of the generated Service Access Classes.
In the variants part of the TDC, all entities (records) of this entity set will be stored, which had been available in the service provider system at the time of generation.

3.3. Generated Test Classes

In the generated classes screen, again the context menu of the class name node provides the option to navigate into the generated class in transaction SE80, where the test’s coding can be modified and the tests can be started.

The generated test classes should be considered as proposals for tests provided by the assistant. It is nearly impossible to provide templates for generated tests, which would fit to every test projects needs.
Responsible developers and testers are encouraged to further refine, extend and enrich these test methods and to add new tests to the test classes.

Be warned that repeated test class generation will overwrite classes and coding potentially modified by the test project.

In contrast to the service access classes, which may need re-generation once the service meta data changes, the test classes might be generated seldom or even never a second time.

3.4. Setting HTTP Connection Data for Test Run

The method SETUP is used to prepare each test run. Here, you can overwrite the settings for the HTTP connection adressing the service provider and the name of the TDC providing test data.

During class creation the connection data used in the assistant step 1 are written into Constructor parameters of the service access classes. Nevertheless, the test classes as callers of service access classes can overwrite and provide their connection options. Note that it is advisable to use HTTP destinations from transaction SM59 to store user credentials in a safe way and to profit from additional options and settings of these destination objects.

3.5. Running the Tests of the Test Classes

You can run the test via the ABAP Unit framework, transaction SUT, with the Integrated ABAP Unit runner with or without debug mode.

4. Integration in eCATT Test Scripts

The scripting language of the test automation tool SAP eCATT (transaction SECATT) includes commands for calling ABAP methods.

Thus, it is easy to use the generated Service Access Classes also from eCATT Test Scripts. Such intergration options allow to combine the call of OData services with other test automation capabilities on SAP business systems.