Changes to Facebook API

Today we had something interesting happen at work.  We had just implemented some Facebook functionality on a project that was ready for release, and just before it was signed off today, a final end to end test was completed.  Part of that test was to test some functionality with social networks.  When the Facebook functionality was tested, it failed.

The functionality was meant to pre-populate the message box with a message that the user updated.  On Wednesday this was working, and today it wasn't.  Lets just say that this caused a few questions to be asked and a few worried people moving the corridors.  How can functionality that was working one day break the next when we made no changes to the code?  After some searching the web (Google is mostly always your friend), I found my answer.  Let me break it down for you.

Firstly, we were using the Javascript Library, specifically the FB.ui functionality. Using the Feed dialog box, we would place our user augmented message into the message box, which the user could then update and publish on their wall.  Now looking at the reference from the Facebook developers page (seen here http://developers.facebook.com/docs/reference/dialogs/feed/ ) the message property is what we used to pre-fill the dialog box. As you can see there is a note on the property that states that the field will be ignored on the 12th July, 2011.  So why was it still working two days ago (3/8 to be specific)?

Before I go into that let me first look at the policy for Apps in Facebook. If you go to the policy page (seen here http://developers.facebook.com/policy/ ) and read section 4 sub section 2 it states that an app will not pre-fill any fields.  (Then in the following sub section it states that the user can give permission for an app to post on their behalf. That is a task for next week.)

So back to the question, why did it just stop working?  If I were to guess, and that is all that I would be doing, I would say that Facebook just got fed up with people not looking at the policies and following them.  Apps should only pre fill the form when the user has done it some where else in the work flow.  I would say that there were plenty of apps that just didn't follow the rules and they just decided to enforce the rules.  And to be honest, I have no problem with them enforcing their policy.

Now, what is the lesson learned from all this?  Is it that we should not trust Facebook?  I would say not.  For me? The lesson is that when you are using third party services you need to be aware that what you don't control what happens with them.  You should intermittently test the services, just to make sure that they work as expected.  That is if you want to make sure that your sites and applications maintain the functionality that you build them with.
Hope this helps!

Test Driven Development

It has been some time since my last post, work has been rather hectic of late.  My downtime has been just that, downtime.  However when I finally got back to my Java oData Consumer I ended up having a good experience in Test Driven Development that I thought I would share.

The next small chunk that I wanted to complete was the XML namespace to package name piece, and then applying that package in my code when trying to get a type of node from a known namespace.  The first part was easy, I wrote my test, got the code working, and vola, I had my XML namespace to package converter.  Not the best work, has hardcoded parts that I would love to remove, but it does the job.  It is something I can refactor later once I have a complete oData consumer.  (A side note, I can add various namespaces and XML definitions easily, so am thinking of also expanding this to allow for a simple RSS consumer in Java, but that is way down the track and I digress.)

The next part I thought was simple. Combine the package name with the expected class name and end up with a complete class name that I can reference in my code when I am trying to create a new node in my tree.  I wrote my test, got it working, then because I had tests that checked the rest of the code I ran those and lo and behold they broke.  So, I fixed them up making sure that I was not breaking anything else, and my code went back to being robust.

The reason why I am saying that this is a good experience in Test Driven Development (TDD) is that if I did this the way I am used to, just manually tested my code, there is almost no chance that I would have picked up the bugs that I created.  By using TDD I had a repository of tests that I have coded against to meet the requirements (each in and of itself a small requirement).  Now I might not have hundreds and thousands of tests to run against my code, but as my codebase grows, the number of tests expands as well to cater for the new code.  No new code should be written where it isn’t to make a test pass.

However, proceed with caution here.  Tests need to be useful and meaningful.  Make sure that you are testing what you think your testing.  Your tests form part of your codebase, make sure you check that they pass regularly, and also make sure that you know what they are testing.  Having heaps of tests that are checking the same thing is pointless. If you have one test to check that your function is working in a set scenario, then move on.  You should write a new test for each scenario.  Also you when you get a bug you should be able to write a test to show that the bug is in the code, then you can debug your code to make sure that the fix is working, and that it hasn't accidently broken anything else.

A tip on testing that I got from Tatham Oddie (@tathamoddie on twitter) is to use the following template for writing a test.  It works in any language.  First create the test (the name and container in code).  Then add 3 comments: Arrange; Act; Assert.  The first part of your test should be to Arrange the objects that your testing, with mocks, creating the object that you want to test.  The second should be the Act part, this is where you perform the function or method that you want to test.  The third is the Assert part, where you check that what you wanted to be the result was indeed the result.

Running a single test with JUnit and Eclipse

So, I had a slight problem with using TDD in Eclipse.  Not a problem as such, more an obstacle that I needed to overcome.  What I wanted to do was to write a test, get that working, then re-run all the tests, check that the changes to the code hadn’t caused another error to correct, then move on to the next test.  I found a few odds and ends about how this could be done, but nothing seemed to work.

After some looking and seeing I was able to get this working.  Here’s how I did it.  For this example, I am using JUnit 4 and Eclipse 3.6.1 (Helios).  Please note, to see the images more clearly just click on the image.

Firstly, go to Run –> Run Configurations

Then, right click the JUnit node in the tree and select New

Enter the name for the run configuration (I have called mine XMLSourceRepository_GetTokensTest)

Select the Method that you would like to test (default is all methods).

Now, I have Android JUnit and Eclipse JUnit launchers, so down the bottom I need to press the hyperlink and the following dialogue box appears. Select the Use Configuration specific settings and then Eclipse JUnit Launcher.

And your done.  Press the run button to run the test, and now it is in your run and debug button menus

So there you have it.  Using JUnit and Eclipse Helios (3.6.1) I have been able to select a single test to run without the overhead of other tests being run as well.

Now, to me, this is rather complex and time consuming if you write a test, change the run configurations to add or alter an existing configuration, make a few changes to change the code, then have to do the whole process again.  It would be easier be able to do this via the source or a test list of some kind.  I am not saying that this isn’t possible, but I couldn’t get it to work.  If you know how to do that, please let me know so that I can correct this post with the easier way of managing tests!