From: Robert L. <rla...@ao...> - 2007-10-11 15:21:20
|
David Bussenschutt wrote: > Why not make the test suite have built-in test services, and completely avoid external dependancies altogether. > > If it was me, I'd make a "fake soap server" testing tool, that only knows how to respond to one specific request with one specific "canned" response, and (in order to test alternate functionalities, I'd make the "canned responses" exactly match those currently given by services like weather, google, etc. THis way, you get the tests against "external" systems (via their canned "known responses" saved to a local configuration) , and don't rely on the 4external systems themselves being up. It also means that the tests work behind big/secure firewalls and on off-line systems. > That works for testing the parsing of the responses from those external services, but does not test the formatting of the original request. That's actually an area that seems to be a bigger problem, at least looking at the interop.soaplite.com page. A cursory glance seems to indicate that there are issues in the formatting of our initial requests... of course this is a ancient version. Just throwing out an idea... What if we attempt to connect to soaplite.com for a list of interop tests? If the connection fails, we get nothing to test and nothing to fail, which seems like it mitigates (to a degree) the firewall issue. If a response is received, the interop test services can be parsed out and tested. This would mean that even when the interop services change, we don't need to release a new version to correct the issue. |