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.wsdlNow 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 1view 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 sourceObject 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.