How do you intentionally cause a SoapFault for testing?

Question

I implemented a SoapClient interface for handling rate requests to the Federal Express Rate request web services. Last night at around 1 am the system was returning soap fault conditions that my code handled with it's response checking (it basically skips over and sends a generic message if it doesn't find a valid rate response) but which isn't handled specifically.

When the service itself is down, I would like to show a more useful message to customers specifically for such faults when the remote services are actually down to perhaps cut down the calls to our tech support. (the generic message says 'try again later', but if I know it's specifically a problem with the FedEx services being down, I can say 'FedEx Rate Service temporarily unavailable' so people will know it's not our site, but theirs)

I've already implemented code to handle a SoapFault condition, but now I have the problem of 'how to test it' as the FedEx rate service was only down briefly last night.

Is there a way to intentionally trigger a soap condition, perhaps even specific soap fault for testing purposes?

Answer 1

It is hard to know when the FedEx Rate (or any other) web service will be down; however, if you would belong FedEx Compatible Solutions Program (CSP), you would get an email with the official date and time in which the test and production services will be unavailable.

Even though that schedule is provided, I have seen the FedEx services (specially Rate) be down without any notice. I might get a fault exception, a failure notification, an error notification, or or time out exception.

Because it is hard to know when the service is actually down, I recommend you to provide the user with a message like "The shipment rates could not be calculated, please, try again later. If the problem persist, please, contact our support team." when the error that you get from the Rate web service has nothing to do with the data provided by the user.

Best!

Answer 2

If you want to intentionally trigger service faults, there are some methods available.

First: Use a different URL for the WSDL. That way, nothing will work, and you'll get a SoapFault exception thrown. But have a look at https://bugs.php.net/bug.php?id=47584 and especially the comment from [email protected]: You have to activate throwing exceptions, suppress errors with @, and it does not work with the XDebug extension loaded.

Actually, you want to do this anyways, because this is the only way to catch absent WSDL resources - and this might happen as well as any other failure.

For anything else, you might want to look at SoapUI and use it to mock the real service and give back SoapFault answers.

Answer 3

I would suggest using SoapUi to mock the service. You can then indicate what response that service will return. Point your appliation to the mock service and test from there. See this post from the SoapUi website:

http://www.soapui.org/Service-Mocking/mocking-soap-services.html