I neet to test a couple of SOAP webservices. What types of tests can I run?
3
-
Stubbing and Mocking Web Services phpunit.de/manual/current/en/test-doubles.htmlPriyank Bolia– Priyank Bolia2009-12-23 10:40:12 +00:00Commented Dec 23, 2009 at 10:40
-
Thank you. But I was looking for functionalities to test the webservice itself and not the corresponding PHP code.powtac– powtac2009-12-23 10:44:16 +00:00Commented Dec 23, 2009 at 10:44
-
then you have to implement those webservices in PHP and call those implementation functions.Priyank Bolia– Priyank Bolia2009-12-23 11:05:07 +00:00Commented Dec 23, 2009 at 11:05
Add a comment
|
3 Answers
It is by far better to test the local consumer classes with mocks of the SoapClient that return pre-recorded result XML, since Unit-Tests are meant to run fast and be independant from remote services.
- Create a Mock class of your Client class (you should have an object wrapper for the SoapClient to be able to test it thoroughly)
- Use
$this->returnValue()to return pre-recorded XML responses or headers that your system expects
See: http://www.phpunit.de/manual/current/en/test-doubles.html
If your system is dependant on the availability of those remote services, you could implement a watchdog service that checks if the ressource is available, but this is not something that should be done in the Unit-Tests themselves.
Kind regards, Thomas
Comments
Testing a SOAP web-service will be quite the same than testing a "local" method : you'll have to call that method, passing it some parameters, and chechink the return value, to verify that it corresponds to the parameters you gave.
Of course, with web-services, the call will be a bit more complicated, as you'll have to work with SoapClient to call the method, but the idea will still be the same.
The biggest problems I see are :
- Web services calls are slow (they go though a network), which means your tests will take time to execute -- which means you won't be able to execute them as often
- With a webservice, you potentially have more than one possible reason for failure ; which means you'll have more troubles finding out why a test failed :
- It can fail because there is a bug -- that's the ideal case
- But it can also fail because the remote server is down
- Or because the network is down
- And probably quite some other possile reasons
- Of course, as the code will be executed on a remote server, and not on the machine that runs PHPUnit, it'll be much harder to get code-coverage (for instance)
Comments
I found http://www.versioneye.com/package/fakeweb it is
FakeWeb is a helper for faking web requests in Ruby. It works at a global level, without modifying code or writing extensive stubs.