Advanced Topics

User rating:
5 (4 ratings)

The content on this page is related to a deprecated version of LoadUI, which has been superseded by LoadUI NG Pro in the Ready! API platform. Click here to learn more.

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:

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.

0.5. Assertions

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:

  1. Define a corresponding property in soapUI and set a default value:


  2. Use that value in your soapUI TestCase via Property Transfers or Property Expansion:


  3. 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.