| IMounsey-Smith wrote: |
|---|
| I would imagine you would set up a testCase1 to generate the XML and store it into a datasink or a variable or some sort. Then another testCase2 that purely executes the request generated in testCase1 . |
Yes, easiest is to save the XML to a TestCase Property and then enable
Add TestCase Properties to Result Message in the
soapUI Runner's settings. In loadUI 2.0 (first beta will be released in one week), this will be enabled by default (there will also be a completely new soapUI Runner).
Then in the request TestCase, make sure that you have a TestCase Property with the same name. A soapUI Runner will automatically override a TestCase Property's value if an incoming message contains a property with the same name.
| IMounsey-Smith wrote: |
|---|
| The only issue I see here is with the generated XML testCase and how the result is handled. I foresee that if you had 2 users executing the same test cases, you could get them overwriting each others generated XML. Then again this depends on how and where the generated XML is stored or used. |
That will not be an issue. LoadUI don't mix users/wire-messages with each other.
However, as with
any load testing scenario, you need to make sure that the handling of any common resources in the Script TestStep is thread-safe. E.g. if you use common variables like files, TestSuite Properties, Project Properties or context-variables (
context.myVariable = aValue), you need to synchronize the access of these among users/threads. In the case of files, soapUI Pro handles this automatically with DataSources.
Regards
Henrik, SmartBear
Alumni