WSDL Refactoring Download Trial - Free 14 day evaluation

Validating SOAP Services

PDF Print E-mail
User Rating:  / 12
Rate this article: PoorBest 

When creating a functional TestCase in soapUI, a very common scenario is that you want to call some SOAP/WSDL service and validate the response to check that the correct result is returned. This is easily done once you have imported the WSDL for the service you want to test:

  1. Add a SOAP Request TestStep to a new or existing TestCase
  2. Add Assertions to the TestStep that validate the response message

Adding the Request TestStep can be done in several ways:

  1. By pressing the “Add to TestCase” button on the top left of the message editor or the “Add to TestCase” action from the Request Popup Menu. This will prompt for which TestSuite/TestCase to add to (or create new ones) and then open the following dialog:

    wsdl-add-request-to-testcase

    Here you can specify how the created SOAP Request TestStep should initially be configured with assertions (see below).
  2. By pressing the SOAP Request button or selecting the corresponding “Test Request” from the popup Insert/Append TestStep menu options in the TestCase editor. This will first prompt for a name and which operation in the project to test, leading to the following dialog:

    wsdl-create-testrequest

    Select the desired options and press OK

In either ways, pressing OK generates the SOAP Request TestStep as specified into the target TestCase:

wsdl-created-testrequest

Double-click it to open the editor which looks exactly like the standard SOAP Request editor apart from the Assertion and Log tabs added at the bottom:

wsdl-testrequst-assertions

An overview on how to work with assertions is available at...; let’s have a quick look at the SOAP-specific assertions available:

  • Schema Compliance - validates the response message against the definition in the WSDL and contained XML Schema
  • SOAP Response - checks that the response is a valid SOAP message, always use this to make sure you are actually getting a response (if no assertions are added a connection error will not cause a failure).
  • SOAP Fault - checks that the response is a SOAP Fault (for negative testing)
  • Not SOAP Fault - checks that the response is not a SOAP Fault
  • WS-Security Status - validates the WS-Security headers and tokens in the response
  • WS-Addressing Response - validates the availability of WS-Addressing Headers in the response;

    wsdl-wsa-assertion

  • JMS Timeout - when using a JMS endpoint that specifies a response channel this assertion validates that the response is received within the specified time (see  ...)
  • JMS Status - when using a JMS endpoint, this assertion validates that no JMS-related errors occurred (see  ...)

Add assertions as desired and you are all set. Of course you can add any number of SOAP TestSteps to a TestCase, chaining them as desired and transferring values between response and request messages with the Property-Transfer TestStep (see  ...)