Тестирование стратегий для Ruby on Rails и Twitter OAuth - PullRequest
8 голосов
/ 12 июня 2009

Я занимаюсь разработкой приложения, которое использует oauth в твиттере и натолкнулось на кирпичную стену, пытаясь выяснить, как проверить oauth в твиттере. В частности, пытаясь использовать Cucumber и Webrat / Selenium для проверки работоспособности. Некоторые этапы процесса регистрации / входа ведут себя по-разному, если пользователь предоставил oauth-доступ к приложению или нет.

Есть ли у кого-нибудь успехи в издевательстве или ошарашивании частей или всей системы OAuth Twitter в их функциях Ruby on Rails Cucumber (или любой другой платформе для тестирования в этом отношении)? Любая помощь будет оценена.

Ответы [ 3 ]

4 голосов
/ 19 августа 2010

Прошло больше года с момента ОП, но я недавно нашел эту статью об использовании TwitterAuth и Cucumber, которая работала для меня.

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

3 голосов
/ 07 сентября 2010

Я использовал насмешку в своих тестах. Я проверил вручную, выяснил, какими должны быть ответы, и переопределил рубиновый камень oAuth. Вот один тестовый пример (с использованием musta) для успешного твита:

 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 - это ответ, который я собрал из своих ручных тестов - я поместил printf в lib / oauth / tokens / access_token.rb: 44: в `post 'для захвата ответа.

В противном случае это практически невозможно протестировать, поскольку, как вы указали, Twitter не может деавторизовать ваше приложение из API и действует иначе, если вы уже авторизовали приложение.

3 голосов
/ 14 июня 2009

У меня нет точного рецепта для твиттера (пока я этого не делал), но, учитывая, что в OAuth есть спецификация, описывающая различные возможные потоки, я бы попытался перечислить каждый из них для рассматриваемого случая и попробовать автоматизировать взаимодействие.

Чтобы помочь вам, вот несколько указателей на соответствующую информацию:

Обычно поток для веб-интерфейса отличается (как вы видели) от того, пользователь не дал авторизацию клиентскому приложению:

  • если пользователь еще не дал авторизацию клиентскому приложению, он перенаправляется на сайт поставщика услуг
    • у поставщика услуг, если пользователь еще не вошел в систему, требуется аутентификация с его учетными данными
    • после аутентификации у поставщика услуг требуется авторизация или отказ в авторизации клиентского приложения / услуги
    • как только он дал ответ авторизации, он отправляется обратно на сайт клиента, который затем может получить токен доступа
  • если пользователь уже авторизовал клиентское приложение / службу, он может использовать токен доступа для обхода этих шагов и доступа к данным / API пользователя у поставщика услуг
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...