Opzioni per il test dello stack completo in Ruby on Rails

Question

Esistono numerose opzioni per il test di stack completo delle applicazioni Rails. Alcuni usano veri browser, altri sono senza testa, altri non eseguono affatto javascript.

Quali strumenti usi o consiglia e perché?

Lista di simulatori del browser o automators:

• Rails supporto integrato per il test di integrazione e funzionali (senza JS)
• Webrat
• Webrat :: selenio
• Selenio
• Celerity (through Culerity)
• Watir
• ...

Lista di DSL test e quadri:

• Rails default (asserzioni, ...)
• Shoulda
• cetriolo
• Capybara (Unified DSL per diversi simulatori di browser)
• ...

Answer 1

Ho usato un sacco di cose durante la mia carriera Rails negli ultimi anni.

Attualmente stiamo lavorando su un'applicazione Rails piuttosto grande su JRuby con una copertura di test molto solida e il nostro stack ha il seguente aspetto.

Unit Testing:

• RSpec copertura dei modelli, aiutanti, biblioteche e controllori. la copertura del controller tende ad essere molto alto livello
• copertura JSpec per un progetto che utilizza un po 'di margine abbastanza taglio JS e HTML 5 magia

Functional Testing:

• cetriolo utilizzando Capybara e Culerity (abbiamo appena convertito da Webrat al fine di ottenere una copertura di JS-pesante front-end da cetriolo)
• selenio che è ora "legacy" e lentamente in fase di migrazione di cetriolo/capibara

Answer 2

Nel progetto al momento sto lavorando, per testare lo stack completo stiamo usando Cucumber con capybara come driver.

Il front-end è molto javascript pesante, ho provato un paio di driver browser senza testa (capybara-envjs e akefalos), ma entrambi stavano fallendo in modo errato i test passati in un vero browser.

Answer 3

Utilizzo Cucumber + Capybara con una combinazione di selenio-webdriver e driver per test su rack. Capybara fa un buon lavoro di astrazione della differenza tra i test in-browser che vengono guidati dal selenio-webdriver per test che può effettivamente verificare che JavaScript funzioni in un browser ma impiega un po 'di tempo per eseguire e testare solo l'HTML prodotto da il controller/azione, che funzionano molto più velocemente ma non testano JavaScript. Ciò significa che lo stesso insieme di scenari e definizioni di passaggi può essere eseguito in un browser o no senza dover mantenere serie duplicate di definizioni di passaggi.

Answer 4

Tutte le applicazioni su rotaia beneficiano di una buona copertura dei test di unità e funzionali, sia che si utilizzi rspec o shoulda ecc., È principalmente una questione di preferenze personali. Sono un fan di shoulda principalmente per i blocchi di contesto che fornisce, rendendo la configurazione degli scenari di test molto più semplice e più chiara da comprendere.

Non penso che i simulatori/gli automatori di browser siano necessari a meno che la vostra applicazione non sia pesantemente javascript. Consiglierei di usarli solo per testare javascript e, a tale scopo, è decisamente meglio guidare un browser reale piuttosto che simulare. L'app su cui sto lavorando è piuttosto javascript pesante e stiamo usando insieme a watir/firewatir per eseguire i nostri test di cetriolo in firefox per le funzioni basate su javascript sul nostro sito.