In our last post, we discussed why it’s so important to monitor your Facebook application for regression since Facebook is continuously updating the Platform. Facebook provides a valuable service by running the Beta Tier for you to test against to catch potential problems before they get out to your users.
Here’s how you can test against the Beta Tier:
Run a second copy of your application
You’ll need to run a second copy of your application as a “regression test” in parallel with your “live” deployment copy. This is because you’ll need to make some fundamental changes to it that cannot be made to your deployment copy. In particular, any API calls that are made to *.facebook.com should be made to *.beta.facebook.com instead. This will allow you to use Facebook’s latest beta code, which is what you really want to test regression against. To do this, you’ll need to edit the libraries that you’re using to interface with Facebook and make this modification. Of course, this assumes that you have access to the source code of the library which interfaces with Facebook. If you don’t, then you’ll need to come up with something clever.
Running a second copy of the app will obviously mean that it must be hosted in a second location which means that it also must be registered with Facebook. Registering a second copy means that you get new Application IDs and secrets, which of course means modification to your sorce code.
At this point you’re going to need to be a bit careful because every time you make an update to your code, you should also update the regression test copy. However, you’ll need to be careful that you don’t overwrite your changes that you’ve made to the ID/Secret or to the library. Perhaps you should consider stripping that code out into its own file so that it’s clear what should be overwritten and what shouldn’t. It’s also probably a good idea to copy things over automatically as part of your build/deploy process.
Choose an automation solution
Clearly you want the process of monitoring to be automated, so you’ll need to choose a solution to automate the monitoring. This can be a commercial solution or something you build yourself. The benefit of using a commercial solution will be that it can be done very economically and will be easy to use. Alternatively, if you want much more control, you can build your own solution around a system such as Selenium.
At this point you’ll also need to create a test user. This is easy enough to do, but remember that you’ll need to add the user as a developer if the application is not public.
Create a test script
Creating a test script should be easy to do. How you do it, of course, will depend on the automation solution you’ve chosen. The difficult and more important thing to do here is to determine the list of actions that the script should contain. You should try to get coverage of all of the possible functions. If this isn’t possible, you should at least get coverage of all of the API calls that the applications makes, as well as all of the FBML tags used.
Execute, monitor and act
Now that you’ve got everything set up, sit back and let the monitoring begin. You’ll want to run your script whenever the Beta Tier is updated, so make sure you’re aware of when it’s going to happen.
Also remember that any changes you make to your app must be deployed to the beta test version also. Most importantly, when the system identifies some regression, stop whatever you’re doing and investigate. Understand the reason for the regression and determine whether it’s real regression or simply a change in design and act accordingly.
Finally, watch the Facebook forums to see what’s happening and if other developers are experiencing any regression. If you find that your app has regressed, be a good community member and make sure you let others know so they can check their apps too.