Given the number of components that go into a complete Web service, it is not surprising that complete testing
General testing principles
Let's review some of the general principles of testing and debugging, which are applicable no matter which toolkits or languages you use:
- Design with testing in mind. A proper choice of abstraction for inputs and outputs will allow testing without the added complexity of a network or a HTTP server.
- Test separate parts wherever possible. Some developers favor the "unit testing" philosophy to enforce testing at a low level. In any case, use language features such as assertions in Java to catch and identify bad inputs to functions.
- Document as you go, use explanatory names for interfaces, classes, methods and variables. One of the advantages claimed for unit testing is that it forces good documentation.
Testing browser clients - Firefox
The most advanced support tools today are found in the free open-source Mozilla Firefox browser, a program that belongs on every serious Web developer's hard disk. I just installed Firefox 3.0 and was delighted to find that the "Live HTTP Headers" tool is now part of the standard download. This tool can capture and display the exact request and response headers for all HTTP requests that go to make up a modern Web page. Inspecting these headers to ensure that the parts of your RIA are being requested correctly is a really good idea.
With Firebug network monitoring enabled, you can capture the request and response headers and see the response size and amount of time each request required. This feature is great for seeing the causes of your application's perceived response speed. You may be surprised to find that a single request resulting in an error is holding up the entire application.
Testing SOAP clients
One problem with testing SOAP clients generated by toolkits such as Axis2 is that it is hard to see exactly what the client is generating. Furthermore, the error messages can be confusing and sometimes you can't tell if the request ever got to the SOAP service. The solution is a tool such as TCPMON that sits between the client and the network, capturing the complete text of request and response. When testing, you direct your client to a localhost address and TCPMON relays requests to the real Web service while capturing the complete text of both request and response. Once captured, requests can be modified and sent repeatedly.
Although originally created for testing SOAP architectures, TCPMON works with RESTful services as well. The first versions of TCPMON were part of the original Axis project, but now the tool has its own Apache Software Foundation project and Web site. The present version has a spiffy graphic user interface making it easy to use.
There are also other open source and commercial utilities that provide the same or expanded functionality. An example is the widely used soapUI tool available in free and commercial versions. The soapUI tool can import WSDL Web service descriptions and use the information to assist in testing. In addition, soapUI can be integrated with common IDEs such as NetBeans.
Testing with recorded requests
The most useful thing about using TCPMON or similar utility is that once you have the complete text of a Web service request or response it simplifies testing various components. For example, SOAP clients build a request as an XML structure in memory and then serialize it. The time consumed doing this makes it harder to create a realistic Web service load test on a simple network. With the complete request in a text file it can be sent to the server with practically no overhead.
Since the captured request and response messages are editable text, you can test the application's response to badly formatted messages. This enables tests that would be impossible with your normal client software, for example, creating SOAP messages with bad signing certificate data.
A Wikipedia article on unit testing.