0.1. Distributing to agents
External resources (such as XLS-files for DataSources or JKS-files for keystores) that your soapUI-project references will not be distributed to agents. A way to get around this is to simply put the external resources in the agent's file system as well, at the same path.
0.2. External libraries
External libraries may be used in Groovy Script TestSteps in soapUI by putting an JAR-file in [soapUI home]/bin/ext and importing the library in the Groovy code. This is documented in detail here.
To be able to run such TestCases in the soapUI Runner, place the same libraries in [loadUI home]/ext, e.g. c:\Program Files (x86)\SmartBear\loadUI 2.0\ext. Failure to do so will result in error messages like this one:
Script2.groovy: 6: unable to resolve class org.apache.http.message.BasicNameValuePair @ line 6, column 1.
0.3. Debugging Failures
When you get failed TestCases in soapUI, you can always open the error log to see what's going on. This is obviously not the case with the soapUI Runner, but there are alternatives:
- Connect the Errors output of the soapUI Runner (the right-most output) to a Table Log. An example of this is shown in Passing Along TestCase Variables - Behind The Curtains.
- Have a look at the log file in [User Home Directory]/.loadui/logs/soapui-errors.log.
0.4. Some words about concurrency
Try to avoid writing to TestSuite or Propject properties from your soapUI TestCase, as these properties are shared among all Virtual Users. TestCase Properties on the other hand, are not shared and therefore a much better option.
Read about the difference between soapUI assertions and loadUI assertions, and how we recommend using the two, here.
0.6. Parameterizing your TestCase
The soapUI Runner's settings dialog allows you to set (and override) any of the TestCase Properties defined in soapUI in the Properties tab. This is useful if you need to control some aspect of your test from inside loadUI; for example if you want to be able to control the target host called by your service requests in your soapUI TestCase you would:
- Define a corresponding property in soapUI and set a default value:
- Use that value in your soapUI TestCase via Property Transfers or Property Expansion:
- Override the value from inside loadUI to load another target system:
To learn how to parameterize like this from the command line, please refer to the chapter Parameterizing Tests in the Getting Started with Automation article.
0.7. The Mock Service Component
The Mock Service Component is used to run a soapUI MockService from loadUI. Read more about it in its article in the component reference section.