Doing a Demo? Don't Rely on an API
And that’s why automated testing of the integration points are very important!
I’m currently involved in a huge project made of multiple components.
To each component corresponds a project team.
My direct upstream dependency is a web API.
In addition to our own unit tests and system tests, we’ve got a set of test scripts that monitor the features we are using. That includes:
- validating the supplier API against their own XML Schemas (Relax-NG in our case) for the API calls used in our system
- If both components use a common set of reference data, a test to check that the data set is the same in the API and in our component
There’s trouble only if the XML Schemas are not updated when changes are made to the API.
As the tests are run regularly we discover changes in supplier’s API quickly. If we don’t have time to make the change in our side (e.g: 5 minutes before a demo) we switch to another instance of the API with the old code (the supplier has a set of rolling instances that guarantees that the previous version of the API is always available on an instance). This is not really applicable with public APIs.
An additional step we have taken is to mock up the results of API calls into static XML. These are normally used for our internal system testing, but if the integration tests with the supplier fails and there isn’t a workable instance of their API, we can switch to the static XMLs (this situation happened once in our project).
This approach will also work with public APIs that output XML like Flickr’s API and Amazon REST service.
Doing a Demo? Don’t Rely on an API: “
Eurobuddy Matt was doing a presentation when there was an API change at GoogleMaps. He’s a quick fella, but I’ve been caught with my pants down.
“
(Via ONLamp.com.)
