My previous blog posts (the series starts here) focused on the server side of OData services using SAP Gateway Foundation. But if you develop OData services, testing them is an integral part of the process.
So, after a brief introduction and terminology clarification, let’s look at the options for testing OData services.
The blog post is intentionally not too detailed and leaves out some technicalities. It is intended to provide ideas and as starting point for discussion. If you want to add further options or elaborate on a listed option, feel free to comment or to contribute with your own blog. If you want to see a separate article about any of the options, just let me know.
In an SAP context, OData services are used in two ways:
In the latter case, any test by the user interface would implicitly test the OData services. But you might also want to test those services without the user interface layer. Martin Fowler calls those tests ‘Subcutaneous Tests’ – check out his blog for the advantages and disadvantages.
In the first case, API is a broad, not well-defined term and so is API testing.
We will use a different terminology and talk about system tests for OData services. Systems tests are black box tests that execute and validate a function belonging to a software product addressing all required components and their integration. That is, no component is replaced by a test-double – the complete stack is tested.
In contrast, integration tests and component tests address single components or the integration of components while isolating certain other components. The application logic exposed by an OData service should be covered by such tests (and unit tests, of course).
OData system tests require an OData client. Your test must address the OData service like any other “external” consumer. This does not imply that the OData client has to reside outside the system. The test just needs to call operations of the OData service as if they originated outside the system. We will an example below.
Having an OData client is one thing. For proper testing, it must be embedded in a test framework that manages test cases, controls test execution, monitoring and test result reporting.
The Gateway Client is a SAPGUI-based test tool for OData services that supports OData versions 2.0 and 4.0. You can access it using transaction
As a part of SAP Gateway Foundation, its big advantage is its proximity to the respective development environment and its integration with other tools, such as Service Maintenance and the Gateway Error Log.
The tool allows you to specify OData requests. It executes them using an http client and can display the response in different formats.
In addition to convenient analysis and control functions, the Gateway Client contains a test case repository in which you can store OData requests together with the expected status code. You can also store an annotated response that can be used to validate the response of subsequent test case executions.
The big disadvantage so far: There’s no official programming interface or surrounding test framework for automation.
You can compare the Gateway Client to the multi-purpose Postman API Client. While Postman supports automated testing quite well, the disadvantage is that it doesn’t “speak” OData natively. It’s just a REST (plus SOAP and GraphQL) client. Nevertheless, if you want to learn about options for testing OData services with Postman, take a look at this blog or the official odata.org site.
eCATT (extended Computer Aided Test Tool) is an option for overcoming the test automation issue. It is a proprietary SAP tool for test automation. A toolset for integrating OData service calls into eCATTs has been provided.
The basic idea is to generate a set of ABAP classes (access classes) based on the OData service metadata (step 2 in the above screenshot). These classes wrap the http-client calls and expose service-specific methods for different requests with service-specific signatures.
Test classes that make use of these access classes are then generated (step 3 in the above screenshot). Of course, it is not only possible to use those test classes in eCATT scripts. You can also use them in tests that are executed by the ABAP Unit Test Framework.
The slight disadvantage of this approach is the generation of additional service-specific artifacts. The advantages are:
The generation of access classes to wrap the http-client wouldn’t be required if there were a dedicated ABAP OData client.
With release 1909 (refer to note 2512479 for related releases), SAP Gateway Foundation provides this kind of ABAP OData Client Proxy for two scenarios:
The remote consumption model was first provided in the ABAP environment on SAP Cloud Platform to consume OData services from an SAP S/4HANA Cloud system in an SAP S/4HANA Extension. A full integration with the ABAP Development Tools is not yet available.
In the remote case, an ABAP proxy model of the remote OData service must be created based on the metadata file of the original OData service. For the local case, the ABAP model of the OData service is being used directly.
The remote consumption scenario is suitable for OData API system tests. A request passes the Internet Communication Framework, the OData library, both the frontend and backend layer of SAP Gateway Foundation, and the complete application logic. Despite its name: it can also be executed within the same system.
The local consumption bypasses the Internet Communication Framework, the OData library and the frontend layer of SAP Gateway Foundation. That’s why it is more of an integration or component test targeting the application logic. It’s possible to use test doubles because in contrast to the remote consumption the request execution is done in the same ABAP session.
If the OData service is created based on a service binding in the new ABAP RESTful Programming Model, the translation between the application logic and the OData protocol is handled by the system. The testing effort can then be targeted to the entity with its application logic.
It does not have to be an ABAP OData client. Several client libraries for other runtime environments are available:
As described above, the availability of an OData client is one thing, the test framework another. But again, there are numerous test frameworks to choose from for all environments and Jenkins, for example, as an automation server.
In most cases, you’ll want to test the functional aspects of the OData service. Does it return correct data for the different entity sets and entities? Are the functions/actions executed correctly? Do CUD operations work properly?
So, why not consume and test the service in the environment in which you’d build your extensions for SAP S/4HANA Cloud anyway?
SAP Cloud SDK supports application development on SAP Cloud Platform end-to-end, especially in a context in which you need to communicate with SAP solutions. It is available for JAVA and JavaScript. And, it contains an OData VDM (Virtual Data Model) which offers an easy access to OData services providing a type-safe, fluent API to execute requests.
Please refer to these blogs on how to generate the VDM for an OData service and how to consume it in a JAVA environment. For JavaScript, refer to this tutorial.
With these resources, you can consume your OData services in a JAVA or JavaScript application which can also be a test application using available test frameworks for these two environments.
We’ve looked at several options for testing OData services that have been created in an ABAP environment. Most of the options allow for test automation providing an OData client that can be used within a certain test framework. Except for the local consumption option of the ABAP OData Client, all options focus on system tests.
So, after a brief introduction and terminology clarification, let’s look at the options for testing OData services.
The blog post is intentionally not too detailed and leaves out some technicalities. It is intended to provide ideas and as starting point for discussion. If you want to add further options or elaborate on a listed option, feel free to comment or to contribute with your own blog. If you want to see a separate article about any of the options, just let me know.
Setting the Stage
In an SAP context, OData services are used in two ways:
- As APIs to expose data to and trigger activities from other systems
- As a communication channel between UI5/FIORI user interfaces and the corresponding backend
In the latter case, any test by the user interface would implicitly test the OData services. But you might also want to test those services without the user interface layer. Martin Fowler calls those tests ‘Subcutaneous Tests’ – check out his blog for the advantages and disadvantages.
In the first case, API is a broad, not well-defined term and so is API testing.
We will use a different terminology and talk about system tests for OData services. Systems tests are black box tests that execute and validate a function belonging to a software product addressing all required components and their integration. That is, no component is replaced by a test-double – the complete stack is tested.
In contrast, integration tests and component tests address single components or the integration of components while isolating certain other components. The application logic exposed by an OData service should be covered by such tests (and unit tests, of course).
OData system tests require an OData client. Your test must address the OData service like any other “external” consumer. This does not imply that the OData client has to reside outside the system. The test just needs to call operations of the OData service as if they originated outside the system. We will an example below.
Having an OData client is one thing. For proper testing, it must be embedded in a test framework that manages test cases, controls test execution, monitoring and test result reporting.
Test Options in the ABAP Environment
SAP Gateway Client
The Gateway Client is a SAPGUI-based test tool for OData services that supports OData versions 2.0 and 4.0. You can access it using transaction
/IWFND/GW_CLIENT.As a part of SAP Gateway Foundation, its big advantage is its proximity to the respective development environment and its integration with other tools, such as Service Maintenance and the Gateway Error Log.
The tool allows you to specify OData requests. It executes them using an http client and can display the response in different formats.
In addition to convenient analysis and control functions, the Gateway Client contains a test case repository in which you can store OData requests together with the expected status code. You can also store an annotated response that can be used to validate the response of subsequent test case executions.
The big disadvantage so far: There’s no official programming interface or surrounding test framework for automation.
You can compare the Gateway Client to the multi-purpose Postman API Client. While Postman supports automated testing quite well, the disadvantage is that it doesn’t “speak” OData natively. It’s just a REST (plus SOAP and GraphQL) client. Nevertheless, if you want to learn about options for testing OData services with Postman, take a look at this blog or the official odata.org site.
Testing OData Services with eCATT
eCATT (extended Computer Aided Test Tool) is an option for overcoming the test automation issue. It is a proprietary SAP tool for test automation. A toolset for integrating OData service calls into eCATTs has been provided.
The basic idea is to generate a set of ABAP classes (access classes) based on the OData service metadata (step 2 in the above screenshot). These classes wrap the http-client calls and expose service-specific methods for different requests with service-specific signatures.
Test classes that make use of these access classes are then generated (step 3 in the above screenshot). Of course, it is not only possible to use those test classes in eCATT scripts. You can also use them in tests that are executed by the ABAP Unit Test Framework.
The slight disadvantage of this approach is the generation of additional service-specific artifacts. The advantages are:
- Integration with other eCATT-related tools, for example, the creation of appropriate test data containers
- Out-of-the-box handling of CSRF tokens and ETags
- Support for draft business object instances
ABAP OData Client Proxy
The generation of access classes to wrap the http-client wouldn’t be required if there were a dedicated ABAP OData client.
With release 1909 (refer to note 2512479 for related releases), SAP Gateway Foundation provides this kind of ABAP OData Client Proxy for two scenarios:
- Remote consumption
- Local consumption
The remote consumption model was first provided in the ABAP environment on SAP Cloud Platform to consume OData services from an SAP S/4HANA Cloud system in an SAP S/4HANA Extension. A full integration with the ABAP Development Tools is not yet available.
In the remote case, an ABAP proxy model of the remote OData service must be created based on the metadata file of the original OData service. For the local case, the ABAP model of the OData service is being used directly.
The remote consumption scenario is suitable for OData API system tests. A request passes the Internet Communication Framework, the OData library, both the frontend and backend layer of SAP Gateway Foundation, and the complete application logic. Despite its name: it can also be executed within the same system.
The local consumption bypasses the Internet Communication Framework, the OData library and the frontend layer of SAP Gateway Foundation. That’s why it is more of an integration or component test targeting the application logic. It’s possible to use test doubles because in contrast to the remote consumption the request execution is done in the same ABAP session.
If the OData service is created based on a service binding in the new ABAP RESTful Programming Model, the translation between the application logic and the OData protocol is handled by the system. The testing effort can then be targeted to the entity with its application logic.
Other Test Options
Non-ABAP Clients
It does not have to be an ABAP OData client. Several client libraries for other runtime environments are available:
- odata4j for JAVA
- Some OData client modules for node.js – see https://www.npmjs.com/
- ODataPy or com/SAP/python-pyodata for Python
As described above, the availability of an OData client is one thing, the test framework another. But again, there are numerous test frameworks to choose from for all environments and Jenkins, for example, as an automation server.
SAP Cloud SDK
In most cases, you’ll want to test the functional aspects of the OData service. Does it return correct data for the different entity sets and entities? Are the functions/actions executed correctly? Do CUD operations work properly?
So, why not consume and test the service in the environment in which you’d build your extensions for SAP S/4HANA Cloud anyway?
SAP Cloud SDK supports application development on SAP Cloud Platform end-to-end, especially in a context in which you need to communicate with SAP solutions. It is available for JAVA and JavaScript. And, it contains an OData VDM (Virtual Data Model) which offers an easy access to OData services providing a type-safe, fluent API to execute requests.
Please refer to these blogs on how to generate the VDM for an OData service and how to consume it in a JAVA environment. For JavaScript, refer to this tutorial.
With these resources, you can consume your OData services in a JAVA or JavaScript application which can also be a test application using available test frameworks for these two environments.
Summary
We’ve looked at several options for testing OData services that have been created in an ABAP environment. Most of the options allow for test automation providing an OData client that can be used within a certain test framework. Except for the local consumption option of the ABAP OData Client, all options focus on system tests.
- SAP Managed Tags:
2 Comments
