Skip to content
This repository has been archived by the owner on Aug 27, 2021. It is now read-only.

Tips

Jump to bottom
Thomas Bouffard edited this page Jul 22, 2014 · 50 revisions

In this page, you will find undocumented features or information only available in Soapui forums

NOTE: in the following, except when mentionned, tips apply to both SmartBear implementations and maven-soapui-extension-plugin

Using the PRO plugin

Note: using the SmarBear OSS plugin (soapui-maven-plugin) or maven-soapui-extension-plugin with runner type OSS does not require any SmartBear license as these plugins do not rely on SoapUI Pro features

SoapUI PRO Legal Concerns

Legally, you need a dedicated license to run the SmartBear pro plugin (the EULA has changed as it was not needed in the past, modification occurs around Summer 2013).
Sources:

When using maven-soapui-extension-plugin with runner type PRO (remember that default runner type is PRO), it seems that you also need a license (because the plugin relies on SoapUI PRO)

SoapUI PRO Technical Concerns

From a technical point of view, no license check is performed, so it is up to you to verify that you are allowed to run the plugin (currently, apply to both SmartBear implementation and maven-soapui-extension-plugin).

### Properties parameters of the "test" goal

soapuiProperties

soapuiProperties parameter sets System properties used to configure Soapui (see some examples bellow in this page).

Maven plugin configuration

  <soapuiProperties>
    <property>
      <name>nameA</name>
      <value>valueA</value>
    </property>
    <property>
      <name>nameB</name>
      <value>valueB</value>
    </property>
  </soapuiProperties>

globalProperties

globalProperties specifies global properties as it can be done in SoapUI GUI (Preferences - Global Properties). These properties can also be set in the settings file (see this forum post) and are overriden by the globalProperties parameter.

Maven plugin configuration (see Soapui forum)

    <globalProperties>
        <globalProperty>nameA=valueA</globalProperty>
        <globalProperty>nameB=valueB</globalProperty>
    </globalProperties>

projectProperties

projectProperties parameter overrides the values that are already in the project (see answer of SmartBear support)

<projectProperties>
  <projectProperty>a=valueA</projectProperty>
  <projectProperty>b=valueB</projectProperty>
</projectProperties>

testSuiteProperties

testSuiteProperties parameter is only available in maven-soapui-extension (ie not in SmartBear implementations).

Implementation status:

Runner Type Since
OSS 4.5.1.3
PRO 4.5.1.4

This parameter override custom testsuite properties in all suites of the project.
If the property does not exist in the suite, it is created

<testSuiteProperties>
  <properties>
    <property>property1=value1</property>
    <property>property2=value2</property>
  </properties>
</testSuiteProperties>

Configuring properties from external file

TODO: IMPROVE DOC (provide example directly instead of just providing a link to SoapUI forums)

It is possible to configure properties from external file for

  • project
  • testsuite
  • testcase
  • mockservice

Source: Soapui documentation about setting properties from the command-line

Global properties

See example in the SoapUI forums

Project properties

See example in the SoapUI forums

Testsuite properties

It is possible to configure test suite properties for a given suite name by providing an external file through the soapui.properties.<TestSuiteName> system properties ie using the soapuiProperties parameter

This is confirmed by this integration test. It works with both SmartBear and maven-soapui-extension implementations (TODO update link to master when feature branch will be merged)

Example: setting properties of the testsuite TestSuite2

  <soapuiProperties>
    <property>
      <name>soapui.properties.TestSuite2</name>
      <value>${basedir}/testsuite2.properties</value>
    </property>
  </soapuiProperties>

Avoid log warnings on startup

If no additional configuration is done, soapui complains about 2 missing folders: ext (for external libraries) and scripts (for externals groovy scripts) Example

14:45:21,583 WARN  [SoapUI] Missing folder [/dev/maven-soapui-extension-plugin/target/it/groovy_log_directory/soapui-pro-4.0.0/./ext] for external libraries

To avoid this, you need to create the 2 folders and store them at the root of the projects. Alternatively, create the folders elsewhere (optionaly with another name) and add configuration to the plugin as in the following

  <soapuiProperties>
    <property>
      <name>soapui.scripting.library</name>
      <value>${basedir}/it/soapui/groovy_scripts</value>
    </property>
    <property>
      <name>soapui.ext.libraries</name>
      <value>${basedir}/it/soapui/ext</value>
    </property>
  </soapuiProperties>

Note that soapui.scripting.library is only releavant when using a PRO runner as external scripting is only a PRO feautre.

### Configuring custom listeners Solution found in the soapui forum

Configure the path to your listeners directory with

  <soapuiProperties>
    <name>soapui.ext.listeners</name>
    <value>${basedir}/it/soapui/listeners</value>
  </soapuiProperties>

Also add your listener jar dependency to soapui external libraries folder or as dependency of the plugin. See this soapui forum thread

### Configuring custom actions

Configure the path to your actions directory with

  <soapuiProperties>
    <name>soapui.ext.actions</name>
    <value>${basedir}/it/soapui/actions</value>
  </soapuiProperties>

Also add your action jar dependency to the soapui external libraries folder or as dependency of the plugin.

### External libraries

Even if it is possible to configure a path to let soapui use external jars (see the previous tip), there is a better way.

You should add maven dependencies to the plugin declaration instead. That way, you let maven manage dependencies resolution and avoid extra tasks to copy dependencies in the ext directory. The SmartBear documentation provide an example which shows how to add the mysql jdbc driver.

Log configuration

Soapui uses log4j 1.x to produce logs.

Using the default configuration

Soapui ships a default log4j configuration which produces by default several files in the project base directory and it is also possible to configure the log destination directory.
Warnings: the smartbear soapui plugin (both open source and pro versions) does not honor this configuration for groovy logs from at least 3.6.1 to 4.6.4 (this is fixed in 5.0.0) but the maven-soapui-extension-plugin does (see #6).

Default log directory

SmartBear implementation
Logs are generated in ${project.basedir}

maven-soapui-extension-plugin
Logs are generated in ${project.build.directory}/soapui/logs/ for the following goals

  • 'convert-project' since 4.5.1.1 (see #25)
  • 'mock' since 4.5.1.2 (see #19)
  • 'test' since 4.0.0.1 (see #5)
  • 'test-multi' since 4.6.3.1 (inherited from the 'test' goal)
  • 'test-verify' only produces maven logs

For other goals, logs are generated in the same directory as the Smartbear implementation does.

Configuring log directory

To configure the log destination directory, you have to set the "soapui.logroot" property. Do the following (the trailing / character is a mandatory in the log output directory path)

    <soapuiProperties>
      <property>
        <name>soapui.logroot</name>
        <value>${project.build.directory}/soapui/my_custon_logs/</value>
      </property>
    </soapuiProperties>

Cleaning log generated in project base directory

Some log files are generated in the project base directory

  • maven-soapui-extension-plugin: no log output directory configured for goals other than these which have a default log directory (see above)
  • smartbear plugin: no log configuration or with log configuration ('groovy.log bug')

In this case, configure the maven-clean-plugin to clean those logs file

<plugin>
  <artifactId>maven-clean-plugin</artifactId>
  <configuration>
    <filesets>
    <fileset>
      <directory>${project.basedir}</directory>
      <includes>
      <include>*.log</include>
      </includes>
      <followSymlinks>false</followSymlinks>
    </fileset>
    </filesets>
  </configuration>
</plugin>

Providing your own log4j configuration file

You can also override the default log configuration by providing a 'soapui-log4j.xml' file in the project base directory. This works both with smartbear plugins (open source and pro) and maven-soapui-extension-plugin. See an integration test for instance this one with maven-soapui-pro 4.5.1

TODO explain how to provide a log4j configuration file that is not stored in the basedir by setting the right java system property soapui.log4j.config (see soapui surefire config or the SoapUI forum)

Configuring Junit Reports

Important note: this feature is only available in maven-soapui-extension-plugin

When setting the junitReport parameter to true in the test or security-test goal, Soapui generates xml files in Junit format (for both successfull and failing tests). These xml files can be used to generate various reports (html, jenkins reports, ...).

The content of the xml files is generated by an instance of a JunitReportCollector class (or subclass). In maven-soapui-extension-plugin, it is possible to configure which class is used as JunitReportCollector by setting the soapui.junit.reportCollector java system property. If not set, the plugin will use a default implementation.

To get more information about how it works, see #58

Rationale

Some users in the Soapui forums have requested to be able to improve the default junit reports.
For more information, see #42

Example

To use it, add the following configuration to the plugin in your pom

<soapuiProperties>
  <property>
     <name>soapui.junit.reportCollector</name>
     <value>my.company.MyJunitCollector</value>
  </property>  
</soapuiProperties>

If you want to use a JunitCollector which is not packaged in maven-soapui-extension-plugin, do not forget to add the dependency to the plugin declaration

Goals supporting the feature

Remember, this feature is only available in maven-soapui-extension-plugin

Goal Runner Type Since
test OSS 4.5.1.4
test PRO 4.5.1.4
security-test OSS N/A (see #60)
security-test PRO N/A (see #61)

Available Junit Reports

These are available direcly with the plugin

Class Since Description
com.eviware.soapui.report.JUnitSecurityReportCollector All Default implementation, as in the SmartBear plugins
org.ktc.soapui.maven.extension.impl.report.NoOpReportCollector 4.5.1.4 example of a custom JunitReportCollector (which does nothing), mainly for testing purpose (see the integration tests related to this feature)

Outside the plugin

Jenkins

DOC IN PROGRESS

Here are some tips when running the test goal and the test-multi goal (maven-soapui-extension-plugin only) and you want to get test results displayed in Jenkins and that Jenkins detect test failures

Note: this may also apply to hudson (feedback appreciated)

Main idea is to configure SoapUI to ignore failures and let Jenkins detect them (see https://github.com/redfish4ktc/maven-soapui-extension-plugin/issues/72#issuecomment-25577410) You also have to set the junitReport to true to let the SoapUI plugin generate junit xml files (which are then used by jenkins for report and failures detection)

links

Clone this wiki locally