When a SOAP project's WSDL changes, SoapUI can use the new definition to:
Update the port binding
Add new operations and requests
Update endpoints in requests
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.
To update our SoapUI project with the new WSDL, right-click on InvoicePortBinding and select Update Definition. Enter the following in the Update Definition window and click on OK:
Definition URL: This is
<chapter1 samples>/soap/invoicev2_impl/wsdl/invoice_v2.wsdl.Tick Recreate existing request with the new schema.
Leave the rest of the checkboxes at their default values.
Click on Yes on the Update Definition with new endpoint popup (although this didn't actually update the endpoint for me!). This should result in
InvoicePortBindingnow showing thecreateInvoiceoperation and request.Next, let's add a new
TestCaseoption forcreateInvoicecalledTestCase – Create Invoice. Also, change the order so thatTestCase – Create Invoiceis run beforegetInvoice TestCase.Add a new
TestStepoption underTestCase – Create InvoicecalledcreateInvoice, and select InvoicePortBinding > createInvoice in the operation popup and just accept default value in the Add Request To TestCase popup.Generate a new empty web service for
invoice_v2.wsdlas per the previous recipe, using Tools | Apache CXF:WSDL Location:
invoice_v2.wsdl.Change
v1tov2in all the paths, packages, and Custom Args.Copy
invoice_v2.wsdlto the root of your classes' folder, for example,<chapter1 samples>/soap/invoicev2/target/classes.
Start the generated invoice v2 server:
cd <chapter1 samples>/soap/invoicev2/target/classes java ws.invoice.v2.InvoicePortType_InvoicePort_Server
If you now run the tests:
The
createInvoiceTestStepoperation will succeed since it doesn't have anyAssertions.The
getInvoice TestStepoperation will fail as expected because our previous implementation is not part of the newly generated invoice v2 service code.
Next, let's add
Assertionto test thecreateInvoiceoperation. Insert the same invoice values as we did in thegetInvoiceTestStepoperation into the request of thecreateInvoice TestStepoperation and addXPath Assertionto check whether the acknowledgmentinvoiceNois 12345:Name: AcknowledgementShouldContainInvoiceNo12345 XPath: declare namespace ns1='http://soapui.cookbook.samples/schema/invoice'; //ns1:Acknowledgement[1]/ns1:invoiceNo[1] Expected Value: 12345
If we now rerun
TestCase:The
createInvoice TestStepoperation will still pass, again thanks to the Apache CXF-generated code passing through theinvoiceNofrom the request to the response.The
getInvoice TestStepoperation will now not pass as expected.
Providing a simple service implementation to pass the tests by storing invoice details between requests and allowing them to be retrieved involves a little more coding than in the previous recipe. So to stay more in the scope of SoapUI, we can take what we need from a completed example service implementation in this chapter's samples. If you have generated the new empty web service stub in step 5, then all that you will need to take are:
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.
Next, recompile and restart the server.
Rerun the tests, and both should now pass!
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:
When SoapUI makes a request to the
createInvoiceoperation, theInvoicePortImpl.createInvoicemethod extracts the invoice details from the request and stores them (usingInvoice.java) in aHashMapkeyed oninvoiceNo. TheinvoiceNovalue is then returned in the acknowledgment response.When SoapUI makes a request to the
getInvoiceoperation, theInvoicePortImpl.getInvoicemethod uses theinvoiceNovalue in the request to retrieve the invoice details from theHashMap(held inInvoice.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.