I’ve been working on a utility for testing mobile apps.

The first stage is testing the web services directly.  I used python’s urllib2 & httplib2 to make requests, parse the results and do verification.  It was my first real foray into python since playing with pickle circa 2001 with raw sockets.  That didn’t last long and I went back to using expat and perl.

This time around I found a really cool XML library for python called amara.  Which is kindof like simplexml for php but way better.  It provides an object tree that is so intuitive to work with you’ll forget you ever worked with Java libraries like Xerces, JDOM, and Castor (from worst to better.)

The second stage was building a mock web service for testing the mobile app without the webservices.  I started by hand crafting XMLs and placing static files (and then PHP templates of XML files plus headers) on a webserver.  This worked okay, but it was limited, laborious, and I kept creating false states from not-really-valid responses.

Once the web services matured, I was able to take actual valid responses and modify them to test states that are difficult to simulate with backend services (which happen to include a test SABRE environment) and legacy airline services.

Then I had an epiphany.  I could put all this together and test the live mobile app and the live web services by intercepting requests from the app, query the web services, and injecting values into them before passing the results back to the device so I can simulate difficult to achieve states like back end error scenarios, cancelled flights, and no seats available — without having to swing an axe around the datacenter, make a bomb threat at an airport, or purchase every ticket on a plane to Hawaii.  All it would take is an app build that points to my test machine running Apache + mod_wsgi.

Only it turns out that the production app only uses JSON, not XML.

Now, I’d recently become convinced (in my blindered little world) that JSON can do everything XML does, only better, and in less space.  But XML has a DOM.  And you can parse an XML document, manipulate it, and spit out a reasonable facsimile of the original XML (with exceptions for whitespace, sibling element ordering, and attribute sequence) — none of which matter.

With JSON, you can get pretty close most of the time, but it turns out that every JSON parser has a different definition of close.  It might be due to the squishiness of the spec or just the relative lack of maturity of the tools, but I don’t know of a tool that you can use that will guarantee your json_encode() will look just like your json_decode() — or that is as nice to work with as Amara.

To be honest I was a bit suprised, but not shocked.  And I’m hoping I’ll get plenty of flames telling me how wrong I am complete with links and examples.

But then I had a second epiphany.  There is a JSON parser that always leaves your json documents the way you want them.  Because there is no encoding or decoding.  As I’m sure you all have known all along, that parser is javascript.  It doesn’t have problems with a squshy spec or immature implementations because it is fully documented in ECMA-262 (Don’t get me started on the scurrilous and spurious claims that it’s actually called “ECMAScript” — as if C were really called ANSI/ISOScript or that there is an association of computer manufacturers in europe developing or a marketing a single browser-based scripting language instead of registering hundreds of hardware and software standards.)

But now it’s implementation time.  I could switch to Jython and import Rhino, but that smells really bad.  It would mean losing my simple webserver solution, trusting tomcat, and jython, and it would take a lot more work than I want to do.  Despite it’s Rube Goldberg appeal, I decided against it.  There might be an easier way to invoke a javascript parser, but why?

The great thing about my python solution is the ease with which I’m doing it.  Adding complexity takes away from my desire to use python.  So, as nice as my flirtation with the snake has been (don’t worry, I’ll be back) it’s time to try something new.  And as a matter of fact, I was thinking of ditching my Apache+mod_wsgi solution and using a simple python web server like web.py so that it would eliminate webserver setup.

Enter node.js.  I’ve only played with it a little, but I read about how LinkedIn is using node.js for their mobile web services.  My one concern is if the tooling is good enough to do intercept, modify, and spit out the webservices with less effort than just building my own mapping classes to marshall and unmarshall the half-dozen or so REST services I have to deal with.

I’ll let you know how it turns out.