Testing Service-Oriented APIs

One of Zend Framework's key strengths and differentiators in the crowded PHP framework arena is its offering of web service consumer components. As of version 1.8.0, these include offerings for Adobe AMF, Akismet, Amazon (including EC2 and S3 support), AudioScrobbler from last.fm, Del.icio.us, Flickr, Google's GData services, Nirvanix, ReCaptcha, Simpy, SlideShare, StrikeIron, Technorati, Twitter, and Yahoo! — and more are planned or under development.

Offering components to interact with web services is relatively trivial — but testing them offers a very different story. For continuous integration purposes, it is typically better not to test against live services as this introduces network latency, and thus slows the testbed. Additionally, many services have API call limits, and automated test suites could easily rise far above these limits. There are also concerns about keeping sensitive API keys or credentials in the repository; some services are paid services, and such information would present a breach of security or contracts.

Over time, the Zend Framework team and contributors have developed a set of practices to address these issues that range from mocking the request and response payloads to offering different tests when credentials are provided via configuration. These practices can lead to well-tested service-oriented components and ensure that the end user experience is as documented.

Matthew Weier O'Phinney works for Zend Technologies Ltd. and is the Project Lead for the Zend Framework.