Stubbing l'authentification de la demande de spec

Lors de la rédaction d'une demande de spec, comment procédez-vous pour des séances et/ou de stub méthodes de contrôleur?
Je suis en train d'écraser l'authentification dans mes tests d'intégration - rspec/demandes

Voici un exemple d'un test

require File.dirname(__FILE__) + '/../spec_helper'
require File.dirname(__FILE__) + '/authentication_helpers'


describe "Messages" do
  include AuthenticationHelpers

  describe "GET admin/messages" do
    before(:each) do
      @current_user = Factory :super_admin
      login(@current_user)
    end

    it "displays received messages" do
      sender = Factory :jonas
      direct_message = Message.new(:sender_id => sender.id, :subject => "Message system.", :content => "content", :receiver_ids => [@current_user.id])
      direct_message.save
      get admin_messages_path
      response.body.should include(direct_message.subject) 
    end
  end
end

Le helper: 

module AuthenticationHelpers
  def login(user)
    session[:user_id] = user.id # session is nil
    #controller.stub!(:current_user).and_return(user) # controller is nil
  end
end

Et ApplicationController qui gère l'authentification:

class ApplicationController < ActionController::Base
  protect_from_forgery

  helper_method :current_user
  helper_method :logged_in?

  protected

  def current_user  
    @current_user ||= User.find(session[:user_id]) if session[:user_id]  
  end

  def logged_in?
    !current_user.nil?
  end
end

Pourquoi il n'est pas possible d'accéder à ces ressources?

1) Messages GET admin/messages displays received messages
     Failure/Error: login(@current_user)
     NoMethodError:
       undefined method `session' for nil:NilClass
     # ./spec/requests/authentication_helpers.rb:3:in `login'
     # ./spec/requests/message_spec.rb:15:in `block (3 levels) in <top (required)>'
InformationsquelleAutor Jonas Nielsen | 2011-04-26
  1. 100

    Une demande spec est une fine enveloppe ActionDispatch::IntegrationTest, qui ne fonctionne pas comme le contrôleur spécifications (qui s'enroulent ActionController::TestCase). Même si il y a une séance de méthode, je ne pense pas qu'il est pris en charge (c'est à dire que c'est probablement parce qu'un module est inclus pour d'autres utilitaires comprend également que la méthode).

    Je voudrais vous recommandons de vous connecter en détachement à toute action que vous utiliser pour authentifier les utilisateurs. Si vous faites le mot de passe "mot de passe" (par exemple) pour tous les Utilisateurs des usines, alors vous pouvez faire quelque chose comme ceci:

    def login(utilisateur) 
post login_path, :login => utilisateur.login :mot de passe => 'mot de passe' 
fin
    • Merci David. Il fonctionne très bien, mais il ne semble pas être un peu exagéré de faire toutes ces demandes?
    • Si je pensais que c'était exagéré, je n'aurais pas recommandé 🙂
    • C'est aussi la façon la plus simple de le faire de manière fiable. ActionDispatch::IntegrationTest est conçu pour simuler un ou plusieurs utilisateurs d'interagir via les navigateurs, sans avoir à utiliser de vrais navigateurs. Il y a potentiellement plus d'un utilisateur (c'est à dire de la session) et plus d'un contrôleur à l'intérieur d'un seul exemple, la session/contrôleur objets sont ceux qui sont utilisés dans la dernière demande. Vous n'avez pas accès avant de faire une demande.
    • Du sens. Merci!
    • J'ai utiliser page.driver.post avec Capybara
    • peut-être un antipattern, selon Jonas Nicklas dans Capybara et les tests Api )
    • Je pense que c'est la bonne solution makandracards.com/makandra/...

    InformationsquelleAutor David Chelimsky
  2. 60

    Note pour Concevoir des utilisateurs...

    BTW, @David Chelimsky la réponse peut être besoin d'un peu de peaufinage si vous utilisez Concevoir. Ce que je fais dans mon intégration /demandes de tests (merci à cette StackOverflow post):

    # file: spec/requests_helper.rb
def login(user)
  post_via_redirect user_session_path, 'user[email]' => user.email, 'user[password]' => user.password
end
    • lorsque j'utilise ensuite le login user1' dans un rspec modèle de spec, je reçois undefined variable locale ou de la méthode 'user_session_path" pour #<RSpec::Core:
    • Cela suppose que vous avez devise_for :users dans config/routes.rb fichier. Si vous avez spécifié quelque chose de différent, vous devrez modifier votre code en conséquence.
    • Cela a fonctionné pour moi bu j'ai eu à le modifier légèrement. J'ai changé 'user[email]' => user.email à 'user[username]' => user.username depuis mon application utilise le nom d'utilisateur de connexion au lieu de e-mail.
    InformationsquelleAutor fearless_fool
  3. 3

    FWIW, dans le portage de mon Test::Unit tests de RSpec, je voulais être capable de se connecter avec plusieurs (concevoir) des séances dans ma demande de spécifications. Il a fallu creuser, mais cela fonctionne pour moi. À l'aide de Rails 3.2.13 et RSpec 2.13.0.

    # file: spec/support/devise.rb
module RequestHelpers
  def login(user)
    ActionController::IntegrationTest.new(self).open_session do |sess|
      u = users(user)

      sess.post '/users/sign_in', {
        user: {
          email: u.email,
          password: 'password'
        }
      }

      sess.flash[:alert].should be_nil
      sess.flash[:notice].should == 'Signed in successfully.'
      sess.response.code.should == '302'
    end
  end
end

include RequestHelpers

    Et...

    # spec/request/user_flows.rb
require 'spec_helper'

describe 'User flows' do
  fixtures :users

  it 'lets a user do stuff to another user' do
    karl = login :karl
    karl.get '/users'
    karl.response.code.should eq '200'

    karl.xhr :put, "/users/#{users(:bob).id}", id: users(:bob).id,
      "#{users(:bob).id}-is-funny" => 'true'

    karl.response.code.should eq '200'
    User.find(users(:bob).id).should be_funny

    bob = login :bob
    expect { bob.get '/users' }.to_not raise_exception

    bob.response.code.should eq '200'
  end
end

    Modifier: correction d'une faute

    InformationsquelleAutor turboladen
  4. -1

    Vous pourrait assez facilement stub de la session ainsi.

    controller.session.stub(:[]).with(:user_id).and_return(<whatever user ID>)

    Tous les rubis opérateurs spéciaux sont en effet des méthodes. L'appel de 1+1 est le même que 1.+(1), ce qui signifie + est juste une méthode. De même, session[:user_id] est le même que l'appel à la méthode [] sur session, comme session.[](:user_id)

    • Cela semble être une solution raisonnable.
    • Cela ne fonctionne pas dans une demande spec, mais seulement dans un contrôleur spec.
    InformationsquelleAutor Subhas