Using stubs to test against a real SOAP client

LegacyForumLegacyForum Posts: 1,669 ✭✭
edited December 2016 in SOAtest
The SOATest tutorial describes how to create stubs and run them test against the SOATest SOAP client. This is fine, but for me the true usefulness of the stubs feature is if it can be run against my 'real' SOAP client (in my case a small GUI widget which consumes the web service). The beauty of testing in this way is that I could tailor the response to see how my client handles unexpected or invalid response data. I would have complete control over the response because it's coming from my own stubs.

Does anyone have any experience of doing this? I'd love to hear if it worked for you and if you encountered any difficulties.

One of the first snags I'm hitting is that SOATest creates an endpoint of its own choosing, which doesn't match the endpoint that my client expects, but I'm hoping it should be easy to get around this by modifying the endpoint in the WSDL so it matches the endpoint that SOATest has chosen for my stub.

Please, if anyone has any experience of using the stubs feature in this way, please share that experience here. I will do the same (assuming my employer does purchase SOATest... right now I'm evaluating it, and I'm quite impressed).


  • LegacyForumLegacyForum Posts: 1,669 ✭✭

    This is the expected behavior for SOAtest. The reason for this because, in order for SOAtest to have the same endpoint, it would have to be run on the same server at the same port as the actual service(meaning that the actual service would have to not be running). This is usually not possible.

    The idea solution would be able to set the endpoint in the client to the SOAtest stub endpoint for testing purposes.
    If this is not possible in your case, then you should be able to take the approach you suggest and using a WSDL with a modified endpoint.

Sign In or Register to comment.