Currently there are few tools that can support testing SOAP interfaces. Both Jmeter and SoapUI are suited for testing soap interfaces. SoapUI is explicitly created for testing SOAP interfaces and Jmeter has a SOAP support since version 2.3.x. I have worked with both tools and I prefer SoapUI. It has an intuitive user interface and is flexible. (Please also have a look at the blog of Jeroen)
You can run SoapUI stand alone but I prefer to integrate these kinds of tools with an automated process. Below you will find instructions for running SoapUI as a part of a maven build. This makes it possible to run your automated SOAP tests in Maven with a build process like Hudson. Combined with automatic deployment it is possible to support an agile software development process that supports frequent delivery of versions and continuous testing.
Maven supports SoapUI with the Maven SoapUI plugin.
Usage:
Add the eviware plugin repository to your repository list.
<pluginRepositories>
<pluginRepository>
<id>eviwarePluginRepository</id>
<url>http://www.eviware.com/repository/maven2/</url>
</pluginRepository>
</pluginRepositories>
Attach to verify phase
By attaching the SoapUI maven plugin to the verify phase your build process runs it automatically in the integration-test phase. The “iso-soapui-project.xml” is the reference to the SoapUI xml file.
<plugin>
<groupId>eviware</groupId>
<artifactId>maven-soapui-plugin</artifactId>
<version>2.0.2</version>
<executions>
<execution>
<phase>verify</phase>
<id>soapui-tests</id>
<configuration>
<projectFile>${basedir}/src/test/soapui/iso-soapui-project.xml</projectFile>
<outputFolder>${basedir}/target/soapui</outputFolder>
<junitReport>true</junitReport>
<exportwAll>true</exportwAll>
<printReport>false</printReport>
</configuration>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
Convert log to a report
The log export of SoapUI can be interpreted like a normal Surefire unit report. By just adding this part to your maven reports section you can generate a nice overview of your test results.
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-report-plugin</artifactId>
<configuration>
<outputDirectory>target/site/soapui</outputDirectory>
<reportsDirectories>
<reportsDirectories>target/soapui/</reportsDirectories>
</reportsDirectories>
</configuration>
</plugin>
</plugins>
</reporting>
Example report.
Soapui plugin unable to load the Classes defined in external groovy file. I have copied that script file into soupui script folder
I am getting below error.
Â
15:45:02,306 ERROR [SoapUI] An error occured [startup failed: Script1.groovy: 1: unable to resolve class <class>
The soapui-settings.xml file needs to be placed in your project root. Same location as your pom.xml.
Alternatively you can add <settingsFile> to your soapui-plugin configuration.
Have a look at http://www.soapui.org/plugin/maven2/properties.html
Good article!
Is there a requirement that soapui-settings.xml file and the
<projectFile> should be at the same level (directory)? And should the project file name end with soapui-project.xml?when i have the projectFile in src/test/soapui folder, i am getting an error that the projectFile cannot be found.
The difference between these tools and the Oracle Specific tools:
– They are independent (not Oracle specific);
– SoapUI has a user interface that is easy to use, especially for non-oracle schooled testers;
– You can run and schedule your test independent of the Oracle infrastructure and make them part of your integrated build-infrastrucure;
– Soap-UI can simulate a proxy so you are able to test your ESB interface without “the other side†(not sure FTP has this);
– There are no costs involved. I do not know the exact licence structure of the Oracle tool.
– Reporting is more accessible for end-users.
Â
Â
Â
Â
Â
Â
Â
Is there any real benefit difference in using these tools as opposed to using the file transport protocol and reporting feature of OSB itself? Each can achieve automated testing?