- From: Glen Daniels <gdaniels@sonicsoftware.com>
- Date: Tue, 18 Apr 2006 20:43:17 -0400
- To: <www-ws-desc@w3.org>
In fulfillment of my long-standing action item, here's a basic template for how we might do the kind of runtime testing we've been discussing. 1) Assume the WSDL from Primer, pointing to a shared service (implemented by W3C, say). The idea of this test is to test client-side Web Service consumption - a server version could also be devised. 2) Point your client at the WSDL, and use it to invoke the service (intentionally leaving out whether this means dynamically calling the service, generating code, etc...) 3) We have a "listener" on the service endpoint which records messages as they arrive. For this kind of configuration, where the server is "canned" and we're really testing the client, it's probably enough just to record the requests and then use XPath assertions in order to check them against the expected contents. That's the basic idea. Some tests using the above: * Test - Simple Confirm that requests matching the checkAvailability schema are sent. * Test - Invalid extension WSDL is modified to contain a "wsdl:required" extension which does not exist. Confirm (via human) that the client fails. * Tests - Valid extensions The following tests assume some new context. We write a simple SOAP module which inserts a <Hello> header into SOAP messages. The module exposes a single property "http://w3.org/2006/wsdl/testModule/message", and the spec says that the (string) value of the message property is the value to insert into the header. In the tests below, test software must implement the module, both in that the WSDL markup is understood and that the runtime does the right thing. - Test, <soap:module> extension Use the <soap:module> syntax to engage this module on the <input> message for the checkAvailability operation. Set the message property's value to "This is a test". (should also have tests confirming this works at the various scopes one could set the property in) Follow procedure above. Confirm that the message on the wire in fact looks like: <soap:Header> <test:Hello>This is a test</test:Hello> </soap:Header> <soap:Body> <gh:checkAvailability> <checkInDate>2006-07-14</checkInDate> <checkOutDate>2006-07-16</checkOutDate> <roomType>single</roomType> </gh:checkAvailability> </soap:Body> - Test, syntactic sugar extension Write a WSDL extension element <test:testModule> which is syntactic sugar for engaging our module. Could do this with a fixed property value (if you see the <testModule/> element, always use the same message) or could say the value of the <testModule> element is the message value. Again, test to make sure the message looks right. ---------------------- This of course just scratches the surface, and more tests like this should be devised for good runtime coverage. --Glen
Received on Wednesday, 19 April 2006 00:46:08 UTC