Cosa testare nel routing di Rails?

Question

Sono curioso di sapere quali persone considerano un test adeguato/completo dei percorsi. Un ragazzo con cui lavoro sembra voler affermare lo ogni itinerario nel nostro file di rotte, indipendentemente dalla norma. Mi sembra che sia una perdita di tempo, ma forse ho torto e c'è un qualche valore in questo che non conosco.

Ci sono alcuni casi in cui posso vedere un certo valore nel routing. Abbiamo ancora un paio di azioni che rispondono alle richieste GET e POST, anche se ho intenzione di sbarazzarmene. Non abbiamo alcun tipo di pazzi vincoli con lambda o altro, ma sembra che valga la pena di provarlo se lo facessimo.

Ma per una normale definizione delle risorse?

resources :foo, only: [:index, :show] 

Abbiamo affermazioni che entrambe queste rotte esiste, affermiamo che sono GET e che vanno al corretto controllo/azione. C'è qualche punto in tutto ciò? Sembra che stiamo solo testando Rails a questo punto.

Su una domanda leggermente correlata, preferisco avere percorsi di risorse definiti come quello sopra (con la parte only: [:index, :show]). Ci sono conseguenze solo nella definizione di resources :foo nel file di rotte se ci sono solo azioni index/show su quel controller?

Mi sembra che stia probabilmente usando solo più tempo e/o memoria, ma è in qualche modo anche un problema di sicurezza o qualcosa di veramente brutto di cui non sono a conoscenza?

Answer 1

principali motivi per verificare i percorsi non raddoppiare-test Rotaie, ma piuttosto per verificare un API rivolto al pubblico.

Questo riduce le regressioni rispetto ai punti di ingresso annunciati indipendentemente dai dati che prendono o restituiscono.

Che cosa livello per testare questi è aperto ad alcuni dibattiti pure; è utile testare la rotta stessa o ha senso solo verificare i dati che entrano/escono? Così facendo anche i test eseguono gli stessi percorsi, e direi che è più prezioso – ma più lento.

tendo a percorsi di prova solo quando direttamente:

• sono un po 'funky, ad esempio, percorsi non bog standard
• ho must respingo alcune rotte
• Durante lo sviluppo preliminare.

I test di percorso preliminare vengono generalmente eliminati dopo averli testati in altri modi.

Answer 2

Verifica le rotte per garantire che le rotte che desidero siano consentite siano aperte ma anche affinché le route da chiudere non funzionino. Ho suddiviso le specifiche di instradamento in tre contesti: percorsi consentiti, percorsi non consentiti e percorsi personalizzati.

ad es. utilizzando RSpec

describe SessionsController do 
    describe "routing" do 
    context "permitted" do 
     it "routes to #create" do 

     expect(post "sessions").to route_to("sessions#create") 

     end 
     ... 
    end 
    context "custom routes" do 
     it "routes 'login' to #new" do 

     expect(get "/login").to route_to("sessions#new") 

     end 
     ... 
    end 
    context "invalid routes" do 
     it "does not route to #edit" do 

     expect(get "/sessions/edit").not_to be_routable 

     end 
     ... 
    end 
    end 
end