A client needs to develop SOAP web services. I’m involved in web services interface specifications and comply with specifications. JMeter and finally using XPath statements. Should not depend on the test unit “green bar”, but it worked.

The need is to test the SOAP messages that play on the network. At least one of the first customers to publish applications SOAP requests and responses from the XML SOAP service, instead of using SOAP kit. We need to ensure that the Web service interface to behave as expected, and the business logic behind the interface changes have no impact on the customer’s application.

Before the actual test in JMeter Google quickly reveals what is suitable for quick and dirty test. Tests can be written with JUnit and unity, but the solution may be in the client’s declaration that the e-mail is preferred. JMeter has a job, but has some problems.

The Recipe

1. Download and install JMeter. (Activation.jar and mail.jar are required for SOAP testing. See installation notes.)
2. Create a new Test Plan.
3. Add a Thread Group to the Test Plan. Check that the number of threads is set to 1 and the number of loops is 1.
4. For each test, add a Web Service (SOAP) Request samplers as a child of the Thread Group. Name them with a numeric identitifier for ease of reference. e.g. “1. Invalid Foo, Valid Bar”. You will need to supply the URL to the WSDL file and a fully formed SOAP request XML document.
5. For each sampler, add as many XPath Assertions as you need to validate the result. XPath expressions can be used to check pretty much everything about the content and structure of XML documents.
6. Add a View Results Tree listener to capture and display the requests and responses. Any tests that fail will be shown in red.
7. Save your Test Plan.
8. Run it.
9. View results by clicking on the View Results Tree.
10. Clear results before running the test again. Results are stored cumulatively, not replaced by each test.