Tosca test repository integration
LiveCompare integrates with Tosca test repositories using two methods:
-
Local
-
REST
LiveCompare supports managed workspaces only. A managed workspace is one that is derived from a Tosca Server Repository workspace.
Local integration method
If you use the Local integration method, Tosca Commander must be installed on the LiveCompare server. Use Tosca Commander to create a managed workspace that will be used by LiveCompare exclusively.
REST integration method
If you use the REST integration method, use Tosca Commander on the Tosca server to create a managed workspace that will be used by LiveCompare exclusively.
Requirements
LiveCompare requires the following in order to connect to a Tosca Test Repository.
- A client ID and client secret.
- A workspace name.
For the REST integration method, LiveCompare requires:
-
Tosca Server REST service URL.
Issues
The following may cause connection problems when using Tosca integration.
Common issues:
- Bad client ID or client secret.
- No dedicated workspace. The Tosca workspace must be for the exclusive use of LiveCompare. See the Requirements section above.
Rare issues:
- LiveCompare cannot access the Tosca Server.
- The common repository uses Windows authentication.
Please see this Knowledge Base article for troubleshooting tips.
Search Tosca Test Repositories
The Search Test Repository action searches Tosca Test Repositories to find matching test assets using a two-phased approach.
Phase 1 - Search modules
- Find all SapEngine and APIEngine modules within the specified SearchPaths that match the supplied set of tokens.
- Each engine has a property that is searched:
- SapEngine: Transaction.
- APIEngine: Resource.
- Each engine has a property that is searched:
Phase 2 - Test cases
- For each module, find all associated test cases (not templates) within the specified SearchPaths that match the supplied set of tokens. These are:
- Test cases that use the module directly via an enabled test step.
- Test cases that use the module indirectly via a reusable test step block.
Reusable test step blocks may be nested. In this case, LiveCompare traverses the hierarchy of blocks look for test cases.
Once the module/test case phase is complete, LiveCompare will optionally search for manual test cases. This search is switched off by default. If To enable the search for manual test cases, carry out the following steps:
-
Log in to LiveCompare as a user with Administrator privileges and click
to go to the LiveCompare studio.
-
In the Administration hierarchy, navigate to the Configuration - Test Repository screen, and set the ScanTestCases field to X (use uppercase).
For live Tosca Test Repository searches (where the Use Cache property is set to ‘false’), the Search Test Repository action checks the specified Search Paths to verify that:
- All parts of each Search Path are valid.
- Each Search Path is synchronized in the Tosca workspace.
If either test fails, the action returns a suitable error message.
For Tosca Test Repositories, the Search Test Repository action returns test cases that match one of the workstates specified in the associated Test Repository definition. If no workstates are listed in the Test Repository’s Workstates field, the action returns all matching test cases, regardless of their workstate.
Tosca data analysis
Changes to data are captured in SAP table keys (TABK) This provides an efficient way to propagate table content changes between systems without having to copy the entire table. A table key identifies the key field values of affected rows and includes the changes to non-key fields.
LiveCompare processes TABKs to identify the key field values of changed data records. For example, if the discount of a sales order type is changed, LiveCompare will identify the affected sales order type (which is a key field).
In the Smart Impact app’s results, LiveCompare filters the test hits to highlight the ones that use data affected by a particular change.
- For each test hit, LiveCompare compares the test step values with the key field values.
- If matched, the test is considered to “HAVE_DATA” making it a relevant test to use to validate the data change.