2011-02-03 14 views
10

hanno trovato alcuni consigli: http://openmonkey.com/articles/2009/03/cucumber-steps-for-testing-page-urls-and-redirectscetriolo reindirizzare

ho aggiunto i metodi di cui sopra nel mio spazio web passi definitons, hanno scritto la mia caratteristica, corse e ottenuto un errore sugli oggetti nil. Dopo alcune indagini, ho notato, non ho risposta e oggetti richiesta, sono nulle

Da web_steps.rb:

Then /^I should be on the (.+?) page$/ do |page_name| 
    request.request_uri.should == send("#{page_name.downcase.gsub(' ','_')}_path") 
    response.should be_success 
end 

Then /^I should be redirected to the (.+?) page$/ do |page_name| 
    request.headers['HTTP_REFERER'].should_not be_nil 
    request.headers['HTTP_REFERER'].should_not == request.request_uri 
    Then "I should be on the #{page_name} page" 
end 

la richiesta e la risposta gli oggetti sono pari a zero, perché?

+1

Sarebbe di grande aiuto vedere la funzione che li chiama. Normalmente avresti un oggetto 'request' a quel punto, ma solo se hai effettivamente fatto una richiesta. – jdl

+0

FYI - su Capybara 1.1.2 Ho dovuto usare 'page.driver.request.env [" HTTP_REFERER "]' –

risposta

22

Stai utilizzando WebRat o Capybara come driver in Cucumber? Lo puoi vedere guardando features/support/env.rb. Sto utilizzando Capybara, quindi il mio include queste righe:

require 'capybara/rails' 
    require 'capybara/cucumber' 
    require 'capybara/session' 

L'impostazione di default usato per essere Webrat ma acceso di recente per Capybara, così un sacco di codice da esempi più anziani sul Web non funziona correttamente. Supponendo che stai usando Capibara anche ...

request.request_uri - Vuoi current_url invece. Restituisce l'URL completo della pagina in cui si trova il tuo autista. Questo è meno utile di ottenere solo il percorso, per cui uso questo helper:

def current_path 
    URI.parse(current_url).path 
end 

response.should be_success - Uno dei più grandi frustrazioni con il lavoro con Capybara (e in una certa misura, cetriolo) è che è decisamente zelante solo interagendo con ciò che l'utente può vedere. È can't test for response codes utilizzando Capybara. Invece, dovresti testare le risposte visibili all'utente. I reindirizzamenti sono facili da testare; solo asserisci su quale pagina dovresti essere. Gli anni '40 sono un po 'più complicati. Nella mia applicazione, che è una pagina in cui il titolo è "Accesso negato", così ho appena prova per questo:

within('head title') { page.should_not have_content('Access Denied') } 

Ecco come mi piacerebbe scrivere uno scenario per testare un link che dovrebbe reindirizzare a volte e non supposto per reindirizzare ad altre volte:

Scenario: It redirects 
    Given it should redirect 
    When I click "sometimes redirecting link" 
    Then I should be on the "redirected_to" page 

Scenario: It does not redirect 
    Given it shouldn't redirect 
    When I click "sometimes redirecting link" 
    Then <assert about what should have happened> 
1

È possibile verificare il codice di risposta in questo modo:

Then /^I should get a response with status (\d+)$/ do |status| 
    page.driver.status_code.should == status.to_i 
end 
1

non qualche senso utilizzare il cetriolo per questo genere di cosa, ma è meglio evitarlo.

Non si può utilizzare una specifica del controller?

-1

ho dovuto provare la stessa cosa e si avvicinò con la seguente per Cabybara 1.1.2

Then /^I should be on the (.*) page$/ do |page_name| 
    object = instance_variable_get("@#{page_name}") 
    page.current_path.should == send("#{page_name.downcase.gsub(' ','_')}_path", object) 
    page.status_code.should == 200 
end 

Then /^I should be redirected to the (.*) page$/ do |page_name| 
    page.driver.request.env['HTTP_REFERER'].should_not be_nil 
    page.driver.request.env['HTTP_REFERER'].should_not == page.current_url 
    step %Q(I should be on the #{page_name} page) 
end 
+0

Questo è sbagliato e non funziona. Non puoi farlo: 'page.driver.request.env ['HTTP_REFERER']. Should_not == page.current_url'. Voglio dire se il tuo percorso in corso dice: '/ users/new' e invii un modulo di restituzione standard per le rotaie e vorresti controllare che ti venga reindirizzato a' index', come è normale, quindi non funzionerà perché hai inviato il modulo a '/ users', quindi il percorso del referrer è'/users' e il percorso dell'indice è '/ users'. Ci sono parole di saggezza nella risposta di ddurdiks. Non licenziarli alla leggera. Nella maggior parte dei casi, perché ti interesserebbe anche come ti trovi in ​​un percorso in un test di integrazione? – Timo

0

vedo questo è una vecchia questione, ma voglio aggiungere la mia risposta, può essere qualcuno a trovare è utile. Cetriolo è un framework di test end-to-end di accettazione (o integrazione come molti lo chiamano), significa che quando lo si utilizza, non bisogna preoccuparsi degli stati intermedi, ma dell'inizio di una richiesta (cioè da dove è la richiesta avviato: fare clic su un pulsante o collegamento, navigare dalla barra degli indirizzi e così via), e il risultato finale (cioè ciò che l'utente vedrà sulla pagina quando il caricamento sarà completato).

Quello che serve qui è una specifica del controller, che è meglio specificata da Rspec, che ti darà un migliore accesso agli stati intermedi nel livello di azione. Un esempio può essere:

describe AController do 
    #specify the action where you expect a redirect 
    describe 'GET action' do # or POST action 
    get :action # or post with post params if the request expected to be a form submition 
    expect(response).to be_redirect 
    end 
end