2013-08-04 7 views
6

Sto provando a scrivere test e codice dell'applicazione per reindirizzare gli utenti che sono già registrati in root_path se provano a CREARE un utente o a visitare il NUOVO percorso dell'utente. .Tutorial Rails Ch. 9 Esercizio 6: La risposta prevista è <200>

Qui ci sono le prove che ho scritto in user_pages_spec.rb:

describe "for signed in users" do 
     let(:user) { FactoryGirl.create(:user) } 
     before { sign_in user } 

     describe "using a 'new' action" do 
     before { get new_user_path } 
     specify { response.should redirect_to(root_path) } 
     end 

     describe "using a 'create' action" do 
     before { post users_path } 
     specify { response.should redirect_to(root_path) } 
     end   
    end 

UsersController:

class UsersController < ApplicationController 
    before_action :unsigned_in_user, only: [:create, :new] 

    def new 
    @user = User.new 
    end 

    def create 
    @user = User.new(user_params) 
    if @user.save 
     sign_in @user 
      flash[:success] = "Welcome to the Sample App!" 
      redirect_to @user 
    else 
      render 'new' 
    end 
    end 

    private 
    # Before filters 

    def user_params 
     params.require(:user).permit(:name, :email, :password, 
           :password_confirmation) 
    end 

    def unsigned_in_user 
     puts signed_in? 
     redirect_to root_url, notice: "You are already signed in." unless !signed_in? 
    end 
end 

I puts signed_in? restituisce false. Presumo che questo sia il problema perché mi aspetterei che restituisse il vero. Ecco gli errori dopo aver eseguito i test usando rspec. Qualsiasi aiuto è apprezzato.

Failures: 

    1) User pages for signed in users using a 'create' action 
    Failure/Error: before { post users_path } 
    ActionController::ParameterMissing: 
     param not found: user 
    # ./app/controllers/users_controller.rb:52:in `user_params' 
    # ./app/controllers/users_controller.rb:20:in `create' 
    # ./spec/requests/user_pages_spec.rb:162:in `block (4 levels) in <top (required)>' 

    2) User pages for signed in users using a 'new' action 
    Failure/Error: specify { response.should redirect_to(root_path) } 
     Expected response to be a <redirect>, but was <200> 
    # ./spec/requests/user_pages_spec.rb:158:in `block (4 levels) in <top (required)>' 

All'interno del file sessions_helper.rb:

def signed_in? 
    !current_user.nil? 
end 

A spec/supporto/utilities.rb:

def sign_in(user, options={}) 
    if options[:no_capybara] 
    # Sign in when not using Capybara. 
    remember_token = User.new_remember_token 
    cookies[:remember_token] = remember_token 
    user.update_attribute(:remember_token, User.encrypt(remember_token)) 
    else 
    visit signin_path 
    fill_in "Email", with: user.email 
    fill_in "Password", with: user.password 
    click_button "Sign in" 
    end 
end 
+0

Invia il codice per signed_in? metodo. Dal momento che sta restituendo qualcosa che non ti aspetti, il problema probabilmente sta lì. – amb110395

+0

aggiunto. Sono nuovo alle rotaie ma mi chiedo se il fatto che abbia firmato? è definito in sessions_helper.rb e sto cercando di usarlo nel controller degli utenti (e non nel controller delle sessioni) pone un problema .. – IkegawaTaro

+0

In certamente causerebbe un problema a meno che non si includa il SessionHelper nel tuo ApplicationController. Sei stato tu? – amb110395

risposta

4

stati in grado di ottenere le prove da superare?

Nel caso in cui non eri, ho avuto lo stesso problema come voi oggi, ed è stato in grado di ottenere le prove di passare facendo due modifiche alle prove - il superamento di un hash user durante la pubblicazione, e utilizzando l'opzione no_capybara su il metodo sign_in, dal get e post non sono metodi capybara e penso che RSpec non si comporti come ci si potrebbe aspettare se passiamo dai metodi capybara a quelli non-capybara all'interno dello stesso test.

describe "for signed-in users" do 
    let(:user) { FactoryGirl.create(:user) } 
    before { sign_in user, no_capybara: true } 

    describe "using a 'new' action" do 
    before { get new_user_path }  
    specify { response.should redirect_to(root_path) } 
    end 

    describe "using a 'create' action" do 
    before do 
     @user_new = {name: "Example User", 
        email: "[email protected]", 
        password: "foobar", 
        password_confirmation: "foobar"} 
     post users_path, user: @user_new 
    end 

    specify { response.should redirect_to(root_path) } 
    end 
end 
+1

Bello! Ho aggiunto il no_capybara: vera opzione al primo test e ora entrambi passano. Non ho passato un hash utente per creare ma ora passa. Immagino che non sia un requisito ... es.dai test dei micropost: descrivere "invio all'azione di creazione" fare prima di {post microposts_path} specificare {expect (response) .to redirect_to (signin_path)} fine – IkegawaTaro

+1

Oh, questo ha senso, perché un hash utente sarebbe solo necessario se Rails esegue effettivamente il metodo di creazione, che è quello che stiamo cercando di prevenire. Grazie - ci stiamo riempiendo le lacune l'uno dell'altro :) – najwa

3

Stessa risposta come Najwa, ma ho usato il utente factorygirl con le guide attributi metodo per evitare la duplicazione:

describe "using a 'create' action" do 
    before { post users_path, user: user.attributes } 

    specify { response.should redirect_to(root_path) } 
end 

aiuta a mantenere i dati disaccoppiati dal codice di prova.

Problemi correlati