Service-oriented architecture (SOA) and web services are becoming more and more popular

in many development projects. In Java or .NET, exposing your business logic component as a
web service is as simple as adding a few metadata annotations. Likewise, once you have a
web service, you can use any client to consume it, right?

Before you make all your web services available to the public, however, you need to make
sure they work. The only way to do this is by writing functional tests for your web services.

So much for the theory. I have seen very few projects that actually spend any time testing the
web services they expose. In most cases, these web services are tested as part of the total
system, using whatever user interface is provided. I myself was guilty of doing this before I
discovered SoapUI.

From the day I discovered SoapUI almost 4 years back, however nothing stops me from
writing functional tests for these web services. SoapUI makes it almost tempting to write tests
using their GUI. You can create new test suites, add test cases, and add asserts to your test
cases. This tool is easy to use; you don’t have to be a Java developer to write functional tests.

The tests you write in SoapUI are very manageable. I constantly hear developers saying, I
have no clue what this test does; I didn’t write it.Tests need to be maintained just as your
code does. Once you download and install SoapUI, you can have functional tests up and
running in minutes. Can you write the same test in minutes without SoapUI? No way.

Developers too frequently write tests with no assert statements. Why even bother writing a
test without asserts? With SoapUI you can easily add many types of assertions. You can add
assert statements with the click of a button. If the ones within SoapUI aren’t sufficient for
your requirements, I am going to show you how to use Groovy within SoapUI, which will
make your testing even easier.

OK. You write you tests using SoapUI, add some asserts, and actually run them occasionally.
This is better than nothing, but still largely pointless. Tests should be integrated with your
build and should be able to be run with one click. Yes, I confess, I am the laziest developer
you will ever see. Why bother doing the same thing over and over again when we can do the
same thing with the click of a button?

If you have automated your builds and they are running as part of your Continuous
Integration, of course, there even isn’t a single click to worry about (now that’s lazy!). SoapUI
comes in handy here as well. You can run the test suites and all the test cases you created
within it and above all you can fail the build just like you would when any other unit test
fails. Cool, isn’t it? I’m excited, are you?

OK. Things are better. Now you have your tests, you have some groovy scripts, and it’s all
integrated with CI. What use are your tests without reports? SoapUI comes to our rescue here
as well. You can generate JUnit reports.
Let’s see how we can accomplish all this. In this article I am going to cover Functional Web
Services testing using SoapUI, but don’t worry, there will be more articles on SoapUI and
Groovy as well as on SoapUI and Continuous Integration in the coming weeks.

Before we begin actually writing tests, we need two things first:

1. Download and install SoapUI from here.

2. Next, let’s get a WSDL from NOAA. I wanted to actually focus more on SoapUI rather than
any one technology to publish your business logic as web services. So, I took the easy route
and found out some interesting things about this publicly available web service.

According to the NOAA web site, this web service allows you to get weather data. It has nine
functions. Here is the actual wsdl from the web site:
http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl
Now that we have SoapUI downloaded and a web service which we can test, let’s start
working.

3. Create a new project within SoapUI; give it a name; and copy and paste the WSDL URL
within it. Things should look like this:

Once you have created the project successfully you should be able to see all nine functions
that are provided to us by NOAA. We are only going to use three of them, as seen below in
the screen shot:
4. Now it’s time to run these requests to ensure that they actually work. Double click on
Request 1. An editor will open up for the LatLonListZipCode request. Enter the zip code for
your city. I did 20904 for Silver Spring. Click the Green button on the Request 1 editor and
you should be able to see the response on the right hand side of the editor.

Try a few more requests with the following data:

a. NDFDgenByDay Request 1
view source
Object 1

print?
1.<ndf:NDFDgenByDay
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

2. <latitude xsi:type="xsd:decimal">39.0138</latitude>

3. <longitude xsi:type="xsd:decimal">-77.0242</longitude>

4. <startDate xsi:type="xsd:date">2008-05-07</startDate>

5. <numDays xsi:type="xsd:integer">1</numDays>

6. <format xsi:type="dwml:formatType"
xmlns:dwml="http://www.weather.gov/forecasts/xml/DWMLgen/schema/DWML.xsd">
12 hourly</format>

7. </ndf:NDFDgenByDay>

b. NDFDgenByDayLatLonList Request 1
view source
Object 2

print?
1.<ndf:NDFDgenByDayLatLonList
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

2. <listLatLon xsi:type="dwml:listLatLonType"
xmlns:dwml="http://www.weather.gov/forecasts/xml/DWMLgen/schema/DWML.xsd">
39.0138,-77.0242</listLatLon>

3. <startDate xsi:type="xsd:date">2008-05-07</startDate>

4. <numDays xsi:type="xsd:integer">1</numDays>

5. <format xsi:type="dwml:formatType"
xmlns:dwml="http://www.weather.gov/forecasts/xml/DWMLgen/schema/DWML.xsd">
12 hourly</format>

6.</ndf:NDFDgenByDayLatLonList>
5. Now that you have some requests working, let’s create a Test Suite and add some Test
Cases.

Follow these steps:

a. Right click on your project node, in our case it is NOAA-Weather-Service. Select the New
TestSuite menu item. A dialog will be displayed; enter the TestSuite name, Silver-Spring-
Test-Suite. Click OK and the Silver-Spring-Test-Suite editor should open. If any suite-wide
initialization is needed, you can do this in the Setup Script, and any cleaning afterwards can
be done in the TearDown Script. We are leaving these blank right now, but in the next part
we are going to use these scripts as well.

b. Let’s add a few Test Cases to this Test Suite. There are many ways to do this, but because
I’m lazy, we will do it the easy way for right now. Right click on each of the Request 1 cases
we ran successfully and add them to the TestCase. Once you add all three, you should see
something like this in your SoapUI editor:
c. Now we have a TestSuite, and 3 Test Cases. Let’s run these tests. Double click on the
Silver-Spring-Test-Suite. The editor should open. Click on the Green button and all three
test cases in this test suite should run successfully.
6. If you open any of these test case editors, you will see that each of them has just a single
assertion: SoapResponse Valid. We will add a few more to make our test cases more robust.
In the LatLonListZipCode test case, I have used the ZIP code 20904, and for this ZIP Code,
the latitude and longitude is 39.0138,-77.0242. To test that this is so, add a simple Contains
assertion, with the value 39.0138,-77.0242. Run the test case and you should see green bars.
Still, how do you know this is actually working? Change the Zip Code to 20794, which is
Laurel (close to Silver Spring), but has a different latitude and longitude. Run the test case
and it complains that our assertion failed, like this:
As mentioned in the SoapUI documentation, we can add many kinds of response assertions:
In almost all agile projects, functional testing starts as soon as you finish a story within an
iteration and the code for it has been unit tested. This is when you will be using SoapUI.

Now that we have tested whether or not the functionality of the Weather Web Service works,
we also need to include negative and boundary conditions. I will leave this to you as an
exercise.

Just remember, create test suites and test cases, add assertions, and run the tests. We never
even opened our favorite IDE. And to top it all, it was easy and fun.

We saw in this article how to use SoapUI to write functional tests. We tried to stay within the
SoapUI itself. Coming up next week is what we do in any enterprise application. We want the
user to log in, get a SessionID back, send this ID back in the Soap Header in all subsequent
requests, and to log out successfully. This is just a scenario, but it is typical of what we do,
right? Make a request, get something unique in the response, use this in subsequent requests,
and so forth.

The next part in this series covers Groovy in detail, how to use properties, transferring
properties from one response to another request, how to set global properties, and much
more. Stay tuned.

Note: The SoapUI project file has been attached to this article. Opening this project we created
is as simple as selecting the Import Project menu item and locating the place where you
stored the downloaded project file. Give a yell if you are encountering any problems.