Unlock the Power of Testing in MuleSoft with SoapUI Maven Plugin

23 Jun, 2023 | 6 minutes read

MuleSoft, a renowned integration platform, empowers organizations to seamlessly connect data, systems, and automate critical workflows. Testing is a crucial aspect of ensuring the reliability and functionality of MuleSoft applications. Enter SoapUI, a powerful open-source tool widely adopted for functional and non-functional testing, particularly in the realm of Web Services. With the SoapUI Maven plugin, developers can seamlessly integrate SoapUI tests and mocks into their Maven builds, streamlining the testing process for MuleSoft projects. In this blog post, we will delve into the SoapUI Maven plugin and unveil its potential in optimizing testing practices within MuleSoft environments.


We will provide a step-by-step guide of integrating SoapUI into the Maven build process in MuleSoft.

SoapUI Tests

First, we need to create а SOAP project and add a wsdl in SoapUI. We will name our project “iw-calculator” and we will use the following wsdl: http://www.dneonline.com/calculator.asmx?wsdl. The web service consists of four operations: Add, Subtract, Multiply and Divide.

We also need to check the Create TestSuite checkbox which will lead to creation of a Test Suite for us.

Next, we need to choose for which operation we want to create a Test Suite. We will write assertions only for the Add operation which adds two integer numbers.

We need to specify the name of the Test Suite. We will name ours “CalculatorTestSuite”.

This is our project structure.

In the image below, we can see the SOAP Request and SOAP Response for the Add operation.

The SOAP Request’s body (on the left) comprises an element representing the operation, which contains two child elements of type integer. In the SOAP response body (on the right), we can observe an element named “operation + Response.” This element contains a single child element, which represents the sum of two integers. Additionally, the web service includes an HTTP status code as part of the response.

In order to ensure that the response returned by the web service aligns with our expectations, we need to define assertions for the “Add” operation. Assertions play a crucial role in validating the received message by comparing it to the expected values or specific criteria. These assertions can be added to the request and help us verify different aspects or content of the response.

It is essential to note that multiple assertions can be incorporated into a request, allowing for comprehensive validation. Each assertion evaluates a specific aspect of the response, and if it fails to meet the defined criteria, it will be marked as unsuccessful.

To facilitate this validation process, we have a range of available assertions that can be utilized. These assertions empower us to check various elements of the response, ensuring its accuracy and reliability. You can explore the available assertions by visiting the following link:


As part of our comprehensive validation process, we will define five assertions to thoroughly assess the response received from the web service. The initial assertion focuses on verifying the validity of the SOAP response itself.

Next, we will add an assertion that checks if the response status code is 200. To do that, we need to go to “Compliance, Status and Standards” and then choose “Valid HTTP Status Codes” from the list. Next, we need to write “200” in the text box that pops up.

For our third assertion, we will check if a string is present in the SOAP response. This assertion is used to search for the existence of a string token in the property value and supports regular expressions. It is also applicable to any property. We will check if “<AddResult>12</AddResult>” string is present in the response. For that purpose we will put the string “<AddResult>12</AddResult>” in the Content text box.

Next, we will use an Xpath expression, because Xpath is the most common locator for XML files and performs traversal through DOM elements and attributes. We will use “XPath Match” assertion from the list. This assertion uses an XPath expression to select content from the target property and compares the result to an expected value. It is applicable to any property that contains XML.

We need to declare the namespaces:

declare namespace soap=’http://schemas.xmlsoap.org/soap/envelope/’;
declare namespace ns1=’http://tempuri.org/’;

The Xpath expression is:


We expect:

<AddResult xmlns=”http://tempuri.org/”>12</AddResult>

Next, we will add Response SLA Assertion. The Response SLA assertion checks whether the response arrives within the specific time limit.

To set up the Response SLA assertion, we need to specify the maximum expected response time. For that purpose, we will write 1000 milliseconds in the text box.

Now we need to send a request in SoapUI and see if we have any failed assertions. We set intA to value 5 and intB to 7. We can see that all of our assertions have passed.

We need to export the SoapUI project, so we can add it to the Anypoint Studio project. The project will be exported as an xml file.

SoapUI Plugin in Anypoint Studio

After we wrote the assertions, we now need to integrate SoapUI and MuleSoft application.

We need to create a project in Anypoint Studio and add the exported SoapUI project to it. Now we need to add the SmartBear Maven 2 repository either to the project or settings.xml file. For that purpose, we are going to add code snippets to the pom.xml file. The following snippet needs to be added to pluginRepositories:


Next, we need to add the SoapUI plugin in the pom.xml file to plugins. iw-calculator-soapui-project.xml specified as projectFile is the name of our SoapUI exported project.


You can find the latest version of the SoapUI Maven plugin on the following link: https://mvnrepository.com/artifact/com.smartbear.soapui/soapui-maven-plugin

The documentation is available on this link: https://www.soapui.org/docs/test-automation/maven/maven-2-x/

The Anypoint Studio project consists of two xml files, one where we define global configurations (HTTP Listener and Web Service Consumer) and one where we have the flow.

This is the flow:

The HTTP listener is configured to listen on localhost on port 8081. We set the path to /iw.

We set the SOAP request by getting the values for the two integers from query parameters.

We set the operation to “Add” in the Web Service Consumer Connector.

Now, we transform the SOAP Response body to JSON.

Run project and tests

In order to run in parallel the application and the test suite we need to add this base command line for builds:

mvn clean package -nsu -DskipMunitTests com.smartbear.soapui:soapui-maven-plugin:5.1.0:test

Now we run the application and we can see in the console that all assertions have passed:

Additionally, a soapui.log file is generated in the project structure, containing the outcomes of the assertions. The command can be also executed via command prompt, where we get the same results:

We can send GET request to http://localhost:8081/iw?a=5&b=7 via Postman and we will get the following response:


SoapUI brings powerful capabilities to validate web services and applications, enabling developers to ensure the reliability and functionality of their MuleSoft integrations. By seamlessly integrating SoapUI tests into the Maven build process, developers can achieve greater code reliability and elevate the overall quality of their MuleSoft applications.

The SoapUI Maven plugin offers the advantage of automating SoapUI tests within the Maven build process, resulting in improved efficiency throughout the development lifecycle. This automation eliminates manual test execution, saves time, and enhances productivity.

By utilizing the SoapUI Maven plugin in your MuleSoft projects, you can streamline your testing process, automate test execution, and confidently deliver robust and reliable MuleSoft applications. Embrace the power of SoapUI Maven plugin and unlock the potential for seamless integration and exceptional quality in your MuleSoft development journey.