Automation Objects

Int4 Suite is primarily designed for application interface testing, featuring a distinctive separation between test data and test configuration. This concept can be found at Int4 Suite Internal Organization.

It is assumed that the test configuration is shared throughout the entire application interface, while test cases may encompass various message and document variants processed via the tested interface. Consequently, the test configuration is stored as an Automation Object, which specifies the interface or object being tested. This Automation Object can be reused across multiple test cases.

Automation Objects encapsulate the configuration for each test execution, detailing the technical specifications of the interface under test, the test conditions, and the necessary data manipulations. Furthermore, Automation Objects can reference additional components, including other objects, UI scripts, database validation definitions, and more.

Depending on the test type automation objects contain multiple sections and parameters. This page of the manual gives the summary and explains general concepts. For more information on each test type, please refer to the dedicated pages of this manual.

Individual Section

The automation object is designed with specific attributes tailored for each test type and related technology to be tested:

• Definition of the interface/object under test: For example, when testing the integration platform like SAP Cloud Integration, it is essential to provide an IFlow name. In the context of UI testing, this could refer to the destination of the Selenium driver, among other specifics.

• Specific parameters: These parameters vary based on the technology being tested and provide vital information for creating and executing test cases. This includes guidance on identifying payloads for formulating input and output data, as well as instructions on triggering test messages within the integration platform.

Common Sections

Additionally, there exists a common set of parameters that are reused across different test types:

• Variables: The Int4 Suite offers functionality for extracting and dynamizing certain payload content. This feature can be employed in reporting, correlating test cases, or replacing historical values with updated ones.

• Number ranges: When used alongside variables, number ranges facilitate the generation of new test document numbers and replacing original number in the payload. The new numbers helps if interface logic prevents duplicates and ensure that automated tests do not overwrite actual manual documents exchanged in test environments with connected systems.

• Data scrambling: This feature allows the definition and overwriting of sensitive sections of payloads with custom values.

Common Payload/Integration Platform Validation Sections

• Payload Validation: The validation of test cases is based on a comparison between historical payloads used for test case creation and their current execution. Payload validations allow the addition of a set of rules to mark or ignore differences such as the current date, time, document numbers, etc.

• Payload Matching: Some integration scenarios permit one-to-many mappings. In such cases, there might be no guarantee that the integration platform will prepare messages in the same order as the historical flow. Payload matching allows for comparing the payloads in the same order.

• Certain test types allow for XSLT manipulation on input and output payloads. This capability is particularly usefull in migration projects and the Test Driven Development approach, where the payload structures of new solution interfaces may differ but contain similar content.

Common Backend Validation Sections

• Backend Validation and Database Validations in SAP ABAP-based systems, such as SAP S/4HANA, specify the set of database tables and fields to extract business documents for comparison (the historical one with a new one created during test execution).

• IDOC Status Validation section is used to override default status handling rules for Inbound and Outbound IDOC test types. Please see the relevant test type (IDoc Inbound) manual page for more details.

• External links allow the addition of a link template to the result report, enabling access to business documents in the system under test that were created during the test case execution.

For convenience and increased clarity, the detailed description of the appropriate section for the tested technology has been duplicated in the automation object chapter dedicated to it. Please consult the respective section of the manual in the following pages.