Service testing crib post

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:

  1. Good path, good data, everything is happy
  2. Non-existent path (404)
  3. Empty script that never returns
  4. Script that returns something that isn’t URLVariables (usually an error message)
  5. Script that returns valid URLVariables including structurally borked XML
  6. 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.

About the Author

I'm an actionscript programmer living and working in a tiny village in the Yorkshire Dales, UK. I used to be a TV reporter, but my inner (and often outer) geek won. I also write stuff. Most recently Head First 2D Geometry.

Visit Stray's Website

Share the post

Delicious It Digg this! Stumble this! Share on Reddit Share on Buzz Share on FriendFeed
  • creynders

    Ah yes, the myriad of things that can go wrong with services. Headache inducing. Maybe an idea for a followup post: how you handle thrown errors, error events, incorrect response data etc. I for one get lost many times, when trying to find a consistent way to deal with those, since there are so many possible errors and depending on the service they need to be dealt with differently.