
SoapUI Cookbook
By :

When a SOAP project's WSDL changes, SoapUI can use the new definition to:
This recipe builds on the previous example to show how SoapUI can help you do this when a new web service operation is added. We then provide a basic test-driven implementation to support the new operation.
The new WSDL defines a createInvoice
operation and can be found in <chapter 1 samples>/soap/invoicev2_impl/wsdl/Invoice_v2.wsdl
.
To save time coding the implementation, you can take either the full service code or just the Java classes you need from <chapter 1 samples>/soap/invoicev2_impl
.
The SoapUI project for this recipe can be found at <chapter 1 samples>/invoice-soap-v2-soapui-project.xml
.
After updating our SOAP project using the new WSDL and SoapUI's Update Definition functionality, we need to add a new failing test for the new createInvoice
operation. Next, we generate an empty web service stub using the new WSDL and the approach shown in the first recipe. Finally, with our failing test, we will provide a basic implementation to pass the test.
<chapter1 samples>/soap/invoicev2_impl/wsdl/invoice_v2.wsdl
.InvoicePortBinding
now showing the createInvoice
operation and request.TestCase
option for createInvoice
called TestCase – Create Invoice
. Also, change the order so that TestCase – Create Invoice
is run before getInvoice TestCase
.TestStep
option under TestCase – Create Invoice
called createInvoice
, and select InvoicePortBinding > createInvoice in the operation popup and just accept default value in the Add Request To TestCase popup.Check Endpoints
Make sure both TestSteps
are now pointing to the new endpoint http://localhost:9002/ws/invoice/v2
. Update Definition only seems to update the request endpoints under the port binding.
invoice_v2.wsdl
as per the previous recipe, using Tools | Apache CXF:invoice_v2.wsdl
.v1
to v2
in all the paths, packages, and Custom Args.invoice_v2.wsdl
to the root of your classes' folder, for example, <chapter1 samples>/soap/invoicev2/target/classes
.cd <chapter1 samples>/soap/invoicev2/target/classes java ws.invoice.v2.InvoicePortType_InvoicePort_Server
createInvoice
TestStep
operation will succeed since it doesn't have any Assertions
.getInvoice TestStep
operation will fail as expected because our previous implementation is not part of the newly generated invoice v2 service code.Assertion
to test the createInvoice
operation. Insert the same invoice values as we did in the getInvoice
TestStep
operation into the request of the createInvoice TestStep
operation and add XPath Assertion
to check whether the acknowledgment invoiceNo
is 12345:Name: AcknowledgementShouldContainInvoiceNo12345 XPath: declare namespace ns1='http://soapui.cookbook.samples/schema/invoice'; //ns1:Acknowledgement[1]/ns1:invoiceNo[1] Expected Value: 12345
TestCase
:createInvoice TestStep
operation will still pass, again thanks to the Apache CXF-generated code passing through the invoiceNo
from the request to the response.getInvoice TestStep
operation will now not pass as expected.InvoicePortImpl.java
: This provides the main functionality.Invoice.java
: This is a JavaBean to store invoice details.More information on these is provided in the next section.
The main learning of this recipe is how to use the Update Definition functionality, and what it does and doesn't update for you. Like in the previous recipe, we have only used a very basic service implementation just to pass the tests. The main points of the service implementation are as follows:
createInvoice
operation, the InvoicePortImpl.createInvoice
method extracts the invoice details from the request and stores them (using Invoice.java
) in a HashMap
keyed on invoiceNo
. The invoiceNo
value is then returned in the acknowledgment response.getInvoice
operation, the InvoicePortImpl.getInvoice
method uses the invoiceNo
value in the request to retrieve the invoice details from the HashMap
(held in Invoice.java
) and return them in the response to SoapUI.Here, we have developed a very simple non-persistent dynamic web service stub. Chapter 3, Developing and Deploying Dynamic REST and SOAP Mocks, also shows how to use in-memory H2 databases to provide a non-persistent, dynamic REST and SOAP mock service functionality. If you would like to persist the request data, then Chapter 9, Data-driven Load Testing With Custom Datasources, uses a SOAP service stub with a simple H2 database backend to persist data.
For Pro version users, the next recipe continues the SOAP web service stub journey by showing how SoapUI WSDL refactoring can help manage more complicated service definition updates.