Enterprise Software

How to test Web services with soapUI

SmartBear's soapUI is a fantastic tool for testing and demoing Web services. Follow these instructions on how to use soapUI to perform Web service testing.

Something that has driven me batty over the years is testing Web services. For better or for worse, I had not worked with them frequently enough to encourage my to stray from the Web service testing tool built into Visual Studio (which is an awful tool).

In the last several months, however, I was dealing with and creating Web services, and I was in desperate need of a better testing system than forcing the system I was using to make a call. I had heard about soapUI from the folks at SmartBear, and I decided to give it a shot. Not only was soapUI exactly what I needed, but it was easy to use too. TechRepublic contributor Tony Patton wrote about soapUI back in 2008; I am going to provide a closer look at using it to perform Web service testing. Installing the tool is simple, and SmartBear offers a "Pro" version and an open source version.

First, you should create a new project. Right-click the empty Projects node on the left, and choose New soapUI Project. Name the project and point it to a WSDL or WADL location. You can have it automatically create a test suite or a simulator of the service if you like. I am also going to make a test suite (Figure A). Figure A

Creating a new project (Click the image to enlarge.)
This creates the basic test layout as seen in Figure B. By expanding the tree and double-clicking the request, you can see a stubbed out request with comments that help you fill it in. Fill in the blanks and click the green Play button to watch it work (Figure C). Figure B

A basic test layout (Click the image to enlarge.)
Figure C

A failed request (Click the image to enlarge.)
It's really nice that you can click the Raw tab for either the request or the response to get a full view of the HTTP request. My experience has been that SOAP services often send critical error information in the HTTP headers and not the XML response (especially authentication issues), so this view allows you to track those errors down. Likewise, at the bottom of the screen you can view the full HTTP log (Figure D), which can let you track the back-and-forth for diagnostics. Figure D

The HTTP log (Click the image to enlarge.)

The request properties in the bottom left corner let you set things like authentication and encoding, and if you need even deeper detail, you can select the endpoint and press Enter to bring up the Interface Viewer. Settings like authentication can be set at the endpoint level in Interface Viewer or the individual request level, depending upon your needs. Interface Viewer allows you to dig deep into the various data structures and types, messages, and other service information exposed by the service.

Conclusion

I've been using soapUI to test and demo Web services, and it has been invaluable to me over the last few months -- I don't know how I was working without it before.

If your needs are slight, use the open source version of soapUI, but if you have more in-depth needs, spring for the Pro version.

J.Ja

Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.

About

Justin James is the Lead Architect for Conigent.

2 comments
pgarnoldjr
pgarnoldjr

My only issue with SoapUI is that you cannot pick enums by a picklist. WcfStorm does this very well, but it has larger issues as an application that still make soapui much better.

Editor's Picks