Integration Testing with Facebook

Share Button

The team and I have spent many hours scratching our heads on how to rigorously test our Facebook integration point.  Facebook drives a very important function of our app that when when they let out the proverbial burp in the form of an API change, policy change, late or early code pushes, or just plain outage, we need to know about it right away.  There are a few ways you can prepare yourself to weather these storms and keep yourself in the know when things stop working.

Inform yourself

The place to start is to change your Email Subscription Settings and start subscribing to at the very least: Platform Status and Weekly Platform Updates.  No amount of automation will entirely supplant the need to know about problems as soon as they happen and you would do yourself well to submit to Facebook’s email bombardment (in reality it’s not all that spammy).

If you would like to create your own solution to stay on top of changes then you can visit the Platform Status page or consume the Facebook API status JSON feed located at the URL https://www.facebook.com/feeds/api_status.php.  The following is an example of the output of this service.

{
   "push": {
      "status": "In Progress",
      "updated": "2012-06-20T19:41:36-07:00",
      "id": 9709914
   },
   "current": {
      "health": 1,
      "subject": "Auth Dialog issues resolved",
      "post_time": "2012-06-19T21:48:18-07:00"
   }
}

For more information on how you can use this service to be alerted and even to potentially to trigger automated test suites then read the Facebook developer blog posted entitled Tracking Platform Status.

Other ways to stay on top of changes and trending topics is to subscribe to cloud sourced Q&A type of websites such as Quora and StackExchange.  Quora’s Facebook-API topic and the Stackoverflow facebook-graph-api tag are excellent resources.

Test Infrastructure

There’s a great question on Quora that has a surprising lack of attention entitled Is there a test suite for the Facebook API?  If I could at the very least test a subset of FB functionality that my app makes use of then I could know when there’s any kind of disruption of service.  So far I haven’t found a public test suite to test the Graph API.

So what to do?  Well, FB has made our job slightly easier by implementing the RESTful Graph API.  REST API’s are great.  They’re a lot easier to consume than more traditional web services and they’re a familiar interface regardless of the language and platform you use.  It’s not too difficult a task to build an automation process that queries the Graph API and asserts the response we expect.  You can do this through an actual integration test of your app’s usage of FB, or you can query the API directly.  A very feature rich tool I’ve used to test web services is known as soapUI.  It can be used to create a list of REST commands to consume and assert results in an automated fashion.  I’ve also used the Facebook C# SDK and just plain old hand rolled HTTP requests in my automated test suites.

Mocking out Facebook

If your Facebook integration point lies on your server side (as it should! see my last post for more details) then it should be a simple matter to mock out your Facebook dependency.  Use the Adapter pattern to wrap calls and any types your chosen SDK may expose so that you can easily mock out calls during your automated testing.  If you don’t need to test Facebook then mock or stub it out.  Your test suite will be much less brittle because of it.

Mocking out dependencies is beyond the scope of this post, but I would recommend reading up on the Dependency Injection pattern and Stubs and Mocks.  If you use C# I would highly recommend the Moq framework.

Facebook Test Users, Spam, and Hidden Posts

When testing your app manually or in automation it’s important to use a Test User Account.  Facebook has a number of proprietary methods to detect spammy apps and user accounts.  If you’re using a real account to do your testing then you’re not only annoying your real friends, but you may also be inadvertently negatively affecting your own and your app’s credibility with Facebook.

If your app publishes to a feed on a Facebook Page then it’s possible for posts be identified as spam by Facebook.  How exactly Facebook qualifies posts as spam is proprietary knowledge, but the community has been able to suss out some of the more obvious reasons.

  1. The post contains keywords that promote a specific product that is considered illegitimate.
  2. The post contains a link to a known site that contains malware or some other kind of unsavory content.
  3. The user or app making the post has a history of being reported as spam.
  4. The same message has been posted across multiple pages or user feeds.

An excellent introduction to the topic of hidden posts has been video blogged by James T. Noble in his post Facebook Hidden Posts – Info & Tutorial.  It also explains how to go about viewing and unhiding invididual posts that may have been accidentally identified as spam by Facebook.  Testing your app can easily be portrayed as “spammy” behaviour so it’s important to use test accounts becaues they shouldn’t affect the credibility of your personal user account or your app.

We ensure that test users are exempt from Facebook spam or fake account detection systems to ensure that you can test your app without worrying about getting disabled. – Test Users, Facebook Developers

Unfortunately, you can’t perform all actions with test users that you can with normal users.  As a result there will be a hole in your testing coverage if your usage of the Graph API overlaps with the following functionality.

Test users can interact with other test users only and not with real users on site.

Test users cannot fan a public Page or create public content on them like writing on a Page’s wall. A Test user can however view and interact with the app tab on the Page if they are associated with that app.

They can be accessed and used by any developer of the associated app.

They only have test privileges on the associated app. This implies that they can use the app in live mode or sandbox mode but cannot edit any technical settings or access insights for that app.

A test user is always a test user and cannot be converted to a normal user account. – Test Users, Facebook Developers

If you use the Facebook C# SDK feel free to make use of the following code snippets in your SetUp and Teardown’s in order to create and delete test users for your tests.

// Create a test user
var appId = "00000000000000000";
var appSecret = "shhhh";
var facebookClient = new FacebookClient(appId, appSecret);

// a comma delimited list of my extended permissions
var extendedPermissions = "read_stream,publish_stream";
dynamic result = facebookClient.Post(string.Format("{0}/accounts/test-users", appId),
					new Dictionary
						{
						  {"installed", "false"},
						  {"name", "My Test User"},
						  {"permission", extendedPermissions}
						});

var testUser = new FacebookTestUser
					{
						Id = result.id,
						AccessToken = result.access_token,
						Email = result.email,
						LoginUrl = result.login_url,
						Password = result.password
					};
// Delete a test user
var appId = "00000000000000000";
var appSecret = "shhhh";
var facebookClient = new FacebookClient(appId, appSecret);

dynamic result = facebookClient.Delete(testUser.Id);

bool boolResult;
bool.TryParse(result.ToString(), out boolResult);

For more information on test users and related Graph API calls check out Facebook’s Test Users page on the Facebook Developers site.

Facebook Beta Site & Release Schedule

Once you have a test suite in place there’s an easy way to stay a few days ahead of the curve.  Facebook will push out code changes to production on Tuesday evenings (PST).  However, they also have a beta site (http://www.beta.facebook.com) that is used to stage upcoming hotfixes and weekly releases.  Facebook encourages all FB application developers to use this site in all their testing activities.  They will push out their weekly updates to the beta site on Sunday evenings which gives developers up to 48 hours to test for potential problems before the push to production.

As of this writing this is the following schedule for weekly code pushes to the beta and production website.  This chart was copied from the Facebook Developers site and entitled Beta Tier and Testing.

Day Beta Tier Production Tier
Sunday Weekly release is staged (evening) Release from Tuesday prior + Hotfixes
Monday Weekly release is staged Release from Tuesday prior + Hotfixes
Tuesday Weekly release is staged Weekly release is pushed
Wednesday Weekly release + Hotfixes staged as they are ready Weekly release + Hotfixes (evening)
Thursday Weekly release + Hotfixes staged as they are ready Weekly release + Hotfixes (evening)
Friday Weekly release + Hotfixes staged as they are ready Weekly release + Hotfixes (evening)
Saturday Weekly release + Hotfixes staged as they are ready Weekly release + Hotfixes (evening)
Share Button