You can extract values from a test and use them in another test using one of the following tools:
If you want to parameterize a request value with a value from another test's response, choose Parameterized from the field drop-down menu.
then use the data source wizard to indicate that you want to use the value of the id element from test 1 (which will be stored in an XML data bank tool that is automatically added to the test suite).
Passing Values from One Test to Another
Parasoft SOAtest supports two primary ways to achieve test chaining, (i.e., extract values from one test to use in a subsequent test):
Using a Data Bank – Capture values for single run
This approach is used in simple cases when values from a single test execution need to be captured for subsequent reuse.
For example, you can configure a test suite that tests a bank’s Web service transactions. Test 1 of that test suite can log on to the service using a User ID, then the SOAP response would return a session ID back to Test 1. Test 2 of that test suite can be configured to use the session ID from Test 1 to perform transactions. You can configure any of the tests in a test suite to use SOAP response parameters as SOAP request parameters.
A test scenario for this case might look like this:
In this case, we are assuming that every time the test suite executes, we use a different ID throughout the scenario, but it is a single ID for each scenario run.
It is important to note that the same principle applies to all SOAtest data bank tools (XML, Browser, Header, JSON, Object, Text). You can extract a single value into any of these data bank tools, then use it in subsequent tests (as a parameterized value, as well as through scripting with com.para-soft.api.ScriptingContext.getValue(String, String). Extracted values are stored as strings.
This functionality is designed to suit a wide variety of customized needs; the example given above is just one sample application.
Using a Data Bank with a Writable Data Source – Capture values to iterate on multiple runs
This case is useful when you need to extract a list of values of an unknown count, then have a test or test suite iterate over every single value that has been extracted. Assume the following test scenario:
In that case, the “Get User Ids” test assumes a service that returns a list (a sequence) of User Ids, and each User ID is extracted and written to the desired writable data source column. The exact number of user IDs can be unknown or variable. After the “Get User IDs” test executes and the Writable Data Source is populated with the values, the scenario proceeds to the remainder of the test suite and the subsequent tests (Test 1 and Test 2) can be parameterized with that writable data source (e.g., by selecting the appropriate data source then parameterizing fields vs. the appropriate columns in that data source). This means that the tests can iterate over it and use up all the IDs that have been written into it by “Get User IDs”. In other words, they will execute for every ID that is retrieved.
Another case where writable data sources are useful if the test that is generating the values retrieves the values one at a time, but iterates over a data source and stores the extracted values into a Writable Data Source. In this case, a sample test scenario might be:
In this example, the “Get and Store User ID” test step will run multiple times: once per each username provided by the “Usernames” data source. For each run, it will write a User ID to the “Captured User IDs” data source. Now that the “Captured User IDs” writable data source got populated (with user IDs), the remainder of the test suite will use these IDs to execute Test 1 and Test 2 with them.
For details on writable data sources, see Configuring a Writable Data Source.
General Rule of Thumb
A general rule of thumb is: