When you identify a WSDL on which to create a collection of test suites, you must tell SOAtest of the messaging pattern – synchronous or asynchronous – employed, and SOAtest will create tests suited to the pattern. Also, you can set SOAtest to enforce policy configurations on a project's WSDLs and SOAP messages. A policy configuration is a set of predefined rules, roughly analogous to coding standards. SOAtest will alert you when a WSDL or SOAP message violates one of the rules, so policy configuration provide a means of enforcing best practices among all your organizations Web-service assets.

A SOAP request's input data can be entered manually; drawn from a data source such as a database, a spreadsheet, a file, an SOAtest-provided Table Editor (a sort of anemic spreadsheet); or even generated by script code. While SOAtest has a particular affinity to Java, it also supports scripts in Python or JavaScript that can be used to extend the behavior of a test.

SOAtest lets you turn a set of functional tests (which is how tests start their lives) into a load test with near flick-of-a-switch ease. Simply select the Load Tests item from the menu and choose how the load is applied (that is, whether the number of virtual users increases linearly, is steady, or tracks a more complicated curve). Once the load testing has started, you can view real-time graphs that plot the current load, as well as request-response turnaround times. You can halt the testing at any point, change the subset of suites being used, and restart.

SOAtest is overrun with useful support tools. Examples are an XML beautifier, various XML encryption tools, and a module that manages callbacks for asynchronous HTTP testing. SOAtest also supports client-side testing. Point it to a WSDL, and it will examine the WSDL structure and create "stubs" that will mimic the Web service's behavior. SOAtest handles testing coming and going, and it has an overall feel of maturity missing from several of the other tools.

Click for larger view.

Peering through the suds
This is a complicated field from which to draw a favorite. If your testing involves more than just Web services, and your development is primarily Java, then tools such as LISA or SOAtest are worth considering, in that they'll let you drive two nails with one hammer. If, however, you are only interested in SOAP-based Web service testing, and your QA staff is relatively new to the technology, SOAPscope is the obvious choice.

On the other hand, your choice may be based more on your philosophy of testing. Specifically, which is better: coding tests or building them visually (in other words, from menu and button selections within a GUI)? Tools such as SOAPSonar, LISA, and SOAPscope have chosen the latter to escape the former. But shielding the user from code necessarily places that user in a constrained environment. Those tools tacitly assume that their GUIs are flexible enough to meet all or most testing demands. I am not so sure. I favor the tools – QEngine and SOAtest – whose scripting capabilities are easily accessed. And of those two, SOAtest does the better overall job.

Finally, you should take advantage of the fact that almost all of these tools – SOAPscope being the notable exception – offer free versions that enable you to sample their capabilities with no time limitations.