Level 3 · Senior Automation · Practice 03

SOAP Testing

A SOAP envelope, a real WSDL, and an XPath assertion that catches a bad response — all in the free edition of SoapUI.

1 Goal

By the end of this exercise you will have a SoapUI Open Source project that imports the WSDL from dneonline.com/calculator.asmx, sends an Add SOAP request with two numbers, and has an XPath Match assertion that fails the test if the returned AddResult element does not equal the expected sum. You will also add a deliberate SOAP fault case and confirm the assertion catches it.

Why this matters: SOAP is not dead — banks, insurers, telcos, and large public-sector systems still expose core services over SOAP. Knowing how to test a SOAP endpoint, read a WSDL, and craft an assertion separates senior automation engineers from people who only know JSON.

2 Install the tool

There are two editions of SoapUI. SoapUI Open Source is free, permanently, with no account required. ReadyAPI is the paid commercial upgrade. For this exercise you only need Open Source. Do not install ReadyAPI.

  1. Go to the SmartBear download page. Open soapui.org/downloads/soapui. There are two big buttons near the top:
    • “Download ReadyAPI Test” — ignore this. It is the paid product.
    • “Download SoapUI Open Source” — click this one.

    You will be redirected to a form that asks for your name and email. Fill it in and click Get SoapUI. You do not have to create an account — the next page gives you direct download links for all three operating systems.

  2. Download the installer for your OS.

    Pick SoapUI-x64-5.7.x.exe. Run it. On the Choose Components screen untick HermesJMS and Tutorials to keep the install small. Accept the defaults otherwise.

    Pick SoapUI-5.7.x.dmg. Open the DMG and drag SoapUI.app to /Applications. Right-click → Open the first time so Gatekeeper lets it through.

    Pick SoapUI-5.7.x-linux-bin.tar.gz (or the .sh installer). Extract it and run:

    tar -xzf SoapUI-5.7.2-linux-bin.tar.gz
    cd SoapUI-5.7.2/bin
    ./soapui.sh
  3. Verify the edition on launch. The splash screen and the title bar must say SoapUI 5.7.x — not ReadyAPI. If you see “ReadyAPI” anywhere in the window chrome, you downloaded the wrong installer: close it, uninstall, and repeat step 1 with the Open Source link.
  4. Dismiss the starter popups. On first launch SoapUI asks if you want to send usage analytics and offers a ReadyAPI trial. Untick analytics, click No thanks on the trial. You are now ready to build your first project.
Do not accept the ReadyAPI trial offer. It converts your workspace into ReadyAPI format and disables Open-Source-only features. If you accidentally click Yes, uninstall, delete ~/.soapuios (macOS/Linux) or %USERPROFILE%\soapui-settings.xml (Windows), then reinstall the Open Source edition.

3 Project setup

  1. Create a new SOAP project. File menu → New SOAP Project. Fill in:
    • Project Name: Bootcamp Calculator
    • Initial WSDL: http://www.dneonline.com/calculator.asmx?WSDL
    • Create Requests: ticked
    • Create TestSuite: ticked
    • Relative Paths: ticked

    Click OK. SoapUI downloads the WSDL, parses the four operations (Add, Subtract, Multiply, Divide), and prompts you to name the generated TestSuite — accept the default CalculatorSoap TestSuite.

  2. Verify the project tree. The left panel should now show:
    Bootcamp Calculator
      CalculatorSoap
        Add
          Request 1
        Subtract
          Request 1
        Multiply
          Request 1
        Divide
          Request 1
      CalculatorSoap TestSuite
        CalculatorSoap TestCase
          Test Steps
          Load Tests
          Security Tests
  3. Save the project. Right-click Bootcamp CalculatorSave Project As.... Save it as bootcamp-calculator.xml in a folder you will remember. SoapUI Open Source projects are a single XML file — easy to commit to Git.

4 Write the request

SoapUI auto-generated an Add request template with ? placeholders. Open Add → Request 1 by double-clicking it. The request pane shows the SOAP envelope.

Replace the placeholders. The body should read:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:tem="http://tempuri.org/">
   <soapenv:Header/>
   <soapenv:Body>
      <tem:Add>
         <tem:intA>7</tem:intA>
         <tem:intB>5</tem:intB>
      </tem:Add>
   </soapenv:Body>
</soapenv:Envelope>

Click the green ► (Submit) button in the top-left of the request editor. The right-hand pane shows the raw SOAP response:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <soap:Body>
    <AddResponse xmlns="http://tempuri.org/">
      <AddResult>12</AddResult>
    </AddResponse>
  </soap:Body>
</soap:Envelope>

Good — the service is alive. Now add the request to the TestSuite so we can assert against it.

  1. Add a SOAP Request test step. Right-click CalculatorSoap TestCase → Test StepsAdd StepSOAP Request. Name it Add 7 + 5. Choose operation CalculatorSoap → Add. When asked, tick Create default assertions and Add SOAP Response assertion. Click OK.
  2. Paste the request body (same as above) into the new test step's request pane.
  3. Add an XPath Match assertion. With the test step open, click the Assertions tab at the bottom. Click the +Property ContentXPath MatchAdd.

    XPath Expression:

    declare namespace ns='http://tempuri.org/';
    //ns:AddResult/text()

    Expected Result:

    12

    Click Save.

  4. Add a fault-path assertion. Click + on the Assertions tab again, choose SOAP FaultsNot SOAP FaultAdd. This fails the test step if the server ever returns a SOAP fault instead of a normal response.

Your final assertion list for the Add 7 + 5 step should contain four entries:

  • SOAP Response (auto-added) — body must be a valid SOAP response
  • Schema Compliance (auto-added) — body must match the WSDL's schema
  • XPath Match — AddResult must equal 12
  • Not SOAP Fault — response must not be a SOAP fault envelope

5 Run & verify

  1. Run the single test step. With Add 7 + 5 open, click the green ► at the top of the step editor. Watch the Assertions tab at the bottom — all four entries should go green with a tick.
  2. Run the full TestCase. Double-click CalculatorSoap TestCase, then click the big green ► in the top-left of the TestCase window. Expected output at the bottom:
    TestCase [CalculatorSoap TestCase] ran with status: FINISHED
      Time Taken: 312ms
      Test Step Results:
        Add 7 + 5 — PASSED
  3. Force a failure to prove the assertion works. Edit the XPath Match Expected Result from 12 to 13 and Save. Re-run the test step. The assertion row turns red and the Log tab shows:
    XPathContains assertion failed for path [declare namespace ns='http://tempuri.org/'; //ns:AddResult/text()]
      Expected [13] but was [12]

    Good — your assertion catches bad sums. Change it back to 12 before moving on.

  4. Run the whole project from the command line (optional). SoapUI ships a headless runner, testrunner.sh (Linux/macOS) or testrunner.bat (Windows), in the bin folder of the install:
    cd /path/to/SoapUI-5.7.2/bin
    ./testrunner.sh -r /path/to/bootcamp-calculator.xml

    Expected tail:

    SoapUI 5.7.2 TestCaseRunner Summary
    -----------------------------
    Time Taken: 487ms
    Total TestSuites: 1
    Total TestCases: 1 (0 failed)
    Total TestSteps: 1
    Total Request Assertions: 4
    Total Failed Assertions: 0
    Total Exported Results: 0
Why an XPath assertion and not just status 200? SOAP services usually return HTTP 200 even when the operation failed — the failure is encoded inside the envelope as a <soap:Fault>. Body-level assertions are the only reliable way to know whether the call actually worked.

6 Troubleshooting

Error loading WSDL — HTTP 403 or connection timeout

Your network blocks outbound HTTP on port 80. Two options:

  1. Try the HTTPS variant: https://www.dneonline.com/calculator.asmx?WSDL.
  2. Or switch endpoint to the InterSystems demo: https://www.crcind.com/csp/samples/SOAP.Demo.cls?WSDL. It exposes an AddInteger operation that behaves the same way — update the XPath to //ns:AddIntegerResult/text() and the namespace to whatever the CRCIND WSDL declares.
XPath Match assertion always fails, even though the value looks right

The XPath is not handling the default namespace. SOAP responses from .asmx services wrap results in xmlns="http://tempuri.org/", so a bare //AddResult/text() will never match. Declare the namespace prefix explicitly at the top of the XPath:

declare namespace ns='http://tempuri.org/';
//ns:AddResult/text()

Use the Declare button on the assertion dialog to let SoapUI generate the namespace declarations for you.

Schema Compliance assertion fails with “WSDL not loaded”

The WSDL was fetched once at project-create time but the cached copy is stale. Right-click CalculatorSoap (the interface node) → Update Definition. Paste the WSDL URL again and click OK. Re-run the assertion.

testrunner.sh: Permission denied on Linux/macOS

The script is not marked executable. Fix it:

chmod +x /path/to/SoapUI-5.7.2/bin/testrunner.sh

If testrunner.sh itself runs but fails with JAVA_HOME not set, SoapUI ships its own JRE inside jre/ — check that folder exists inside the install directory. If it does not, your install is corrupt; reinstall from the SmartBear download page.

7 Challenge

Extend the test suite

  1. Add data-driven tests for all four operations. Use a Groovy test step or the built-in DataSource (Open Source supports Properties-backed data). Feed in five input pairs per operation with expected results. Each iteration should run against the corresponding SOAP operation and XPath-assert the result. Total: 20 assertions, one click to run.
  2. Catch a real SOAP fault. Add a new test step Divide by zero that calls Divide with intB=0. Replace the Not SOAP Fault assertion with a SOAP Fault assertion and an XPath Match on //faultstring/text() expecting the string returned by dneonline. Confirm the test passes only when the server returns a fault.