It's always the same issue… you write unit tests for a web-service, giving you a feeling of confidence about the correctness of your code. Then the service provider changes the response without notifying you. Suddenly your implementation doesn't work anymore, but even your continuous integration server says it's “all green”.
So what happened?
Surely the fixture files you used are outdated, and since they won't get updated automatically your tests don't stand a chance to detect the change.
Wsunit to the rescue
Implemented as a PHPUnit test listener, once configured wsunit will request a new response every time you run your test suite. It saves the response to your test's fixture file to verify the correct behavior of your implementation. Therefore you probably want to run this test suite as a separate job on your continuous integration server so you don't disturb the developers when doing their job.
Furthermore, wsunit keeps every ‘old' responses (aka fixture files) enabling you to find the differences between the current response and an old response.
How does it work?
After configuring the test listener in the PHPUnit configuration file, the central point of interest is the wsunit configuration file. Here you define which test (identified by it's name) will send a request to which location together with what query parameters.
If you now run the test suite the test listener detects that there is a request to be sent and fetches the requested data from the defined location. After a conversion to XML the response will be stored in a fixture file named after the executed test.
The test now just uses the fixture file to verify the correct implementation of your code.
Since the header and response body are converted into a XML structure it is fairly easy to check it's content by using PHPUnit's ‘assertXml*' assertion methods.
Further reading
A complete description how to install and set up wsunit is written down in Bastian's blog.