Services have such a hard life. Only one way to succeed and so many different ways to fail. *sigh*
To save myself from having to repeatedly trawl my brain for those different ways, I’m capturing them here.
The various scenarios I test, for a service that returns URLVariables which include XML data and some sort of boolean signifier of success/failure, are:
- Good path, good data, everything is happy
- Non-existent path (404)
- Empty script that never returns
- Script that returns something that isn’t URLVariables (usually an error message)
- Script that returns valid URLVariables including structurally borked XML
- Script that returns valid URLVariables and valid XML but the boolean ‘did we win?’ is set to false
Depending on the data being returned, and the process that just took place on the server, there may be further investigation of the validity of the data, and sometimes I’ll also add a time-out test, but the 6 above are my staples.
By using a consistent return-data signature for a whole project, I only need one set of server-side scripts to call on for 3-6 in all my service tests.
That’s it. As you were.