Question

I’m about to start work on a large project that will involve providing a significant number of web services.

We’ll be using the Java platform, so, of course, we’ll be making heavy use of JUnit, Hudson, etc. (although I’m not sure that matters at all.)

We’re looking for a set of best practices and/or tools for testing the web services. We’ll have several goals in mind:

1. Obviously, we need to prove that the services behave correctly. This means issuing web service calls, receiving the responses (checking them for correctness), and then, probably issuing another web service call to ensure that the system is in the new state that we want it to be in post-original call (and, obviously, checking that response for correctness.)

2. We’ll need to collect response times.

3. We must be able to execute the test cases automatically (jUnit style, but against a running system, not against individual code units.)

4. It would be incredibly cool if non-developers (technical business users) could “author” the test cases. They aren’t XML experts (and will never be,) so expecting them to create the XML files is not realistic. But they are subject matter experts, so giving them a “form” to fill out that would generate the XML file is realistic. However; there will likely be far too many disparate services for us to custom-build each of these “forms.”

Any thoughts, best practices, or lessons learned would be appreciated.

Answer 1

We use SOAPUI to do the functional testing initially. However, SOAPUI is not good for regression and load testing.

Next step, we load the XML into JMeter.

It can drive load from multiple machines and we can easily stress our servers to the limits.