Functional Web Services Testing Made Easy with SoapUI - Part 1

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.