views:

928

answers:

3

I am developing an application that utilizes twitter oauth and ran into a brick wall trying to figure out how to test twitter oauth. Particularly trying to use Cucumber and Webrat/Selenium to do test the functionality -- Certain steps in the registration/logon process behave differently if the user has given oauth access to the app or not, among other things.

Has anyone out there had any success mocking or stubbing parts or all of the Twitter OAuth system in their Ruby on Rails Cucumber features (or any other testing framework for that matter)? Any help would be appreciated.

+2  A: 

I have no precise recipe for twitter (not having done exactly that until now), but given that OAuth has a specification describing the different possible flows, I'd try to enumerate each of them for the case at hand, and try to automate the interaction.

To guide you, here are a few pointers to relevant information:

Usually the flow for web based is different (as you have seen) whether the user has not given authorization to the client application:

  • if the user has not yet given authorization to the client application then it is redirected to the service provider site
    • at the service provider is the user was not already logged in it is required to authenticate with his credentials
    • once authenticated at the service provider it is required to authorize or deny authorization to the client application/service
    • once he has given the authorize response it is sent back to the client site which can then get an access token
  • if the user had already authorized the client application/service then it can use the access token to bypass those steps and access users' data/API at the service provider
LucaM
+1  A: 

It's over a year since the OP, but I recently found this article about using TwitterAuth and Cucumber that worked for me.

http://blog.zerosum.org/2009/7/13/twitter-auth-integration-testing

Jordan Brock
+1  A: 

I used mocking in my test cases. I tested manually, figured out what the responses should be, and overrode the ruby oAuth gem. Here is one test case (using Shoulda) for a successful tweet:

 context 'cork/tweet' do
    setup do
      response = Net::HTTPResponse.new("1.1", 200, "")
      Net::HTTPResponse.any_instance.stubs(:body).returns JSON_RESPONSE
      OAuth::AccessToken.any_instance.stubs(:post).returns(response)
      post :create, :cork_id => @cork.id, :message=>MESSAGE     
    end
    should_respond_with :redirect
    should_change('Tweet.count' , :by => 1) {Tweet.count}
    .. and so on

JSON_RESPONSE is the answer I collected from my manual tests - I put a printf in lib/oauth/tokens/access_token.rb:44:in `post' to capture the response.

Otherwise this is almost impossible to test, b/c as you point out, Twitter has no way to deauthorize your application from the API, and acts differently if you have already authorized the application.

Rob