In the previous article, I discussed Web service testing from the client point of view. Now I would like to look at the server side. For testing full systems you will obviously have to have a working client, but BEFORE you get to that point there is a lot of work to do. If your architecture has followed the best practices, there will be many components which can be tested outside the server environment.
The "unit testing" philosophy
The intent behind unit testing is to provide a framework by which individual units of source code can be shown to be behaving properly, both when initially constructed and after the project has evolved to include revised goals. This philosophy involves construction of considerable amounts of code that does not appear in the final product, but is only used in testing and is thus contrary to the instincts of the hard-pressed programming team trying to meet a deadline.
Even if you don't go the full unit testing route, the principle of designing your code so that the parts can be tested separately is still valid. Naturally testing the parts is not sufficient to guarantee that the final product will do what you want, only that various parts work properly. Only testing of the full system with multiple clients will reveal performance and threading problems.
Unit testing tools
The open-source JUnit framework is very popular with Java programmers. The basic framework has been extended by a variety of open source add-ons. One extension is the SQLUnit testing framework, which is aimed at testing of database stored procedures. Support for the JUnit framework is available for both the NetBeans and Eclipse IDEs.
Back end testing
If your Web service requires a database connection you should plan to do some realistic load testing with typical actions outside the server environment. I say this because if your final service has performance problems, the inevitable first question will be about how much delay is the database response time and how much time is consumed with the rest of the service code.
Monitoring the running Web service
OK, you have done all the unit testing and now it is time to put the service online, hit it with real requests, and watch how it responds. JAMon is an open-source and very powerful tool for monitoring any Java application. For the most powerful and detailed monitoring you need to modify your code to start and stop "monitor" functions, but you can also get a lot of information on any Java based HTTP Web service application simply by adding a "filter".
In order to demonstrate how easy it is to get started with JAMon, I downloaded the latest JAMon package (version 2.7) and set up a filter for a specific application with the following additions to the deployment descriptor (web.xml). This configuration sends all HTTP requests to the filter which passes the unmodified request to the original application after starting a "monitor". When the response is done the monitor is stopped and statistics recorded.
<filter> <filter-name>JAMonFilter</filter-name> <filter-class>com.jamonapi.JAMonFilter</filter-class> </filter> <filter-mapping> <filter-name>JAMonFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
In order to take advantage of JAMon's remote monitoring capability I also installed the HTML/JSP based monitor administration functions with appropriate security restrictions. After making a few requests to the monitored application, I opened the administration JSP and was blown away by the detailed monitoring results presented. For each distinct URL the table showed the number of hits, first and last access time, number of active requests, and a statistical breakdown of response time in milliseconds. By default monitoring statistics are presented as an HTML table but you can select output as XML, CSV or MS Excel format.
Monitoring Java memory use
Many performance problems with Web services are related to memory use. In spite of Java's intrinsic memory management there are plenty of ways a poorly designed Web service can gradually consume memory and crash at inconvenient times. Java version 6 comes with several performance monitoring and troubleshooting tools which can be connected to a running JVM. Some of these are labeled as "experimental" so you might want to look into JProbe, a more refined tool.
JProbe was one of the first Java memory monitoring tools. Now in version 8.0, JProbe is frequently recommended. In addition to memory monitoring JProbe can track threads and monitor performance down to the line of code. Although JProbe is commercial software, you can download a 10 day free trial version and there is a free Eclipse plugin for memory dump analysis.
Testing with recorded requests
Typical SOAP clients build a request as an XML structure in memory and then serialize it, a rather time consuming process. Testing the service with requests generated this way limits the amount of load you can generate on a small network and also makes it hard to test the response to client errors. As I described in the previous article, tools such as TCPMON or soapUI let you record the complete text of a client request as a text file, which can be replayed for load testing. Generating a request from the recorded text is much faster than executing a SOAP client.
One reason not to depend on your SOAP client for server testing is that if your service uses WS-* security related protocols, it is hard or impossible to force a SOAP client to create an illegal request. For complete confidence in your server application, you need to be sure that it correctly catches all input errors. Starting with a legal recorded request, you can try modifying various headers and SOAP message contents, for example digital signatures.