You can download a zipped sample project here with several request steps for which you can create and experiment with your own XPath assertions. The service returns information about holidays in several countries; e.g., it returns a list of holidays in a given year, the date of a given holiday, etc. Also, it doesn't use CDATA-- as I discussed in previous posts, services that make extensive use of CDATA require some extra scripting to get them to work with XPath. Download the project, unzip it, and import it into your soapUI workspace (if you want to create your own project from scratch, the WSDL for this services is at http://www.holidaywebservice.com/Holidays/HolidayService.asmx?WSDL).
Let's walk through creating a simple XPath assertion. Once you've imported the project and opened it in soapUI, run the GetHolidayDate test request in the GetHolidayDate test case; the response should look something like this:
SoapUI's XPath assertions allow you to confirm that a specified value in your test request's response XML matches some expected value. Let's create an assertion that verifies the request is returning the expected date-- in other words, that the value of the GetHolidayDateResult element is '2013-01-01T00:00:00'. Open the test step editor and expand the Assertions panel, if necessary (click on the Assertions button at the bottom of the editor window). Open the Add Assertion dialog; the XPath Match assertion is available in the Property Content group.
After selecting the XPath Match assertion type, the XPath Match Configuration dialog is launched:
Once in this dialog, click on the Declare button above the top panel-- soapUI scans the test response to try to identify any namespaces used and automatically creates corresponding declarations:
For those of you unfamiliar with namespaces (and those of you who are may want to skim the next few paragraphs), these provide a way to avoid naming conflicts in XML. For example, you may have two web services that both return an element named "Addressee". Associating each "Addressee" element with a different namespace ensures that each remains unique. Namespaces are generally defined within XML tags using the following syntax:
xmlns[:prefix]="someNamespaceHere"
The colon and prefix are optional. If the namespace is defined without specifying a prefix (e.g.,
xmlns = "http://www.someName.com"), it applies to the element for which it's defined and children of that element (assuming they don't have namespace prefixes or their own xmlns attribute defined in the same way). If the namespace is defined with a prefix (e.g., xmlns:ns = "http://www.someOtherName.com"), XML nodes can be associated with that namespace by using its defined prefix and a colon (e.g., an element labelled ns:Element1 would be associated with the namespace "http://www.someOtherName.com").Let's return to our example. Look again at the GetHolidayDateResult element in the response above. Its namespace ("http://www.27seconds.com/Holidays/") is specified as an attribute of its parent element, GetHolidayDateResponse. Cross-checking this with the soapUI-generated declarations, we can see this namespace was declared for our XPath expression using the prefix "ns1". We can now write our XPath expression using the correct namespace prefix. Type the following in the XPath Match Configuration dialog below the namespace declarations:
//ns1:GetHolidayDateResultThe leading double-slashes signify that we want to find an instance of the GetHolidayDateResult element wherever it occurs in our XML tree. Click on the "Select from current" button below the XPath Expression panel to evaluate the expression-- it should return the value "2013-01-01T00:00:00". Save the assertion, giving it a meaningful name (so you know at a glance exactly what's passing or failing); in subsequent test runs, the assertion will be re-evaluated and passed or failed accordingly.
As I mentioned at the beginning of this post, namespaces can get a little tricky. While soapUI will help you out by automatically generating namespace declarations, you're on your own when it comes to using those namespaces correctly in your XPath expression-- if you enter an incorrect namespace prefix (or forget to use one where one is needed), you'll simply get a message that a match can't be found. In fact, if you see this behavior and you can't find any obvious errors (e.g., typos), a namespace prefix is frequently the culprit and might be the first thing you'll want to double-check. Note also that soapUI's auto-declared prefix for a given namespace may not necessarily match the prefix defined in the response XML; in this case, you want to use soapUI's declared prefix.
Obviously, this is a very simple example; in the next post (which I promise won't be six weeks from now) we'll look at some more complex expressions.
