2009-07-25 9 views

risposta

7

Penso che Webrat sia più di quello che ti serve. Per il test dei feed XML, non è necessario un simulatore di browser come Webrat che carichi le pagine e analizzi tutti i markup (collegamenti, moduli, ecc.) Quando non si dispone di pagine HTML.

Piuttosto hai bisogno di qualcosa come Curl (http://curl.haxx.se) o Curb (su rubyforge, che sono legature di rubino per Curl), o Patron (su rubyforge).

Queste librerie possono creare un'intestazione di richiesta secondo le proprie preferenze (ad esempio impostando Content-Type, scegliendo tra GET POST POST DELETE HEAD ecc.) E ottenere la risposta, e probabilmente seguire i reindirizzamenti 302 quando necessario.

La risposta restituita, può essere trasformata in oggetto XML e i parser XML disponibili per Ruby possono essere utilizzati per testare l'output. Inoltre, puoi scrivere classi XMLMapping (su rubyforge) per convertire l'output XML in oggetti Ruby e testarne gli attributi, ecc. Questo è molto più pulito, IMHO.

+0

Ok Questo è stato davvero utile. Sto usando Curb e XMLMapping per testare la mia app. Funziona molto bene tranne che per qualche codice sporco sottostante. Ma immagino di poter avere qualche codice sporco nei test. – Waseem

2

Una volta impostati i percorsi RESTful, dovresti essere in grado di utilizzare Webrat per visitare i diversi percorsi. È quindi possibile verificare che ciascun percorso restituisca XML che soddisfi le proprie aspettative.

Ecco un post sul blog che descrive come testare l'output XML in RSpec: Testing XML output

Webrat è un browser senza testa, il che significa semplicemente che è possibile simulare un browser senza dover aprire un vero e proprio browser come FireFox sul tuo macchina di sviluppo. Ciò significa che puoi semplicemente digitare qualcosa come "visita" utenti/"" nelle fasi definite e simulare un utente che accede alla tua applicazione.

Infine il Pragmatic book on RSpec (ancora in versione beta), è una grande risorsa su come utilizzare Cucumber, Webrat e RSpec insieme e guidare lo sviluppo di applicazioni con BDD.

+0

Thanks :) Non ho alcun front-end la mia app che significa che se non ho un pulsante "Elimina" a disposizione per distruggere una particolare risorsa. Ora AFAIK Webrat non ti consente di richiedere un URL particolare con un verbo HTTP specifico (GET, POST ecc.). Come dovrei procedere verso questo problema? Posso farlo facilmente con Rspec ma non supporta più "User Story".È una domanda diversa a parte. :) – Waseem

+0

È possibile simulare il metodo GET semplicemente visitando un URL specifico. Per simulare i verbi PUT o DELETE, dovresti essere in grado di usare set_hidden_field "_method", "PUT" o set_hidden_field "_method", "DELETE" prima di visitare il link. Non ho ancora provato questo. –

+0

La documentazione di set_hidden_field per webrat. Dice "verifica che esista un campo nascosto nella pagina corrente e imposta il valore sul parametro specificato." Poiché non ho alcun front-end per la mia app, non ho alcun hidden_field o form_field o pulsanti con cui interagire. Penso di aver bisogno di un modo con cui posso richiedere URL di rest diversi con diversi verbi HTTP. qualcosa come this ma che può essere automatizzato. – Waseem

9

La funzione visit di webrat accetta un http_method come secondo parametro. È inoltre possibile testare il vostro api come nel seguente regola cetriolo:

When /^I restfully delete (?:|the)user "([^\"]*)"$/ do |login| 
    visit(path_to("user \"#{login}\" page"), :delete) 
end 
0

stavo cercando di farlo e rimasto bloccato in un grave problema con restful_authentication (utilizzando SAMA, uno del modello interno di restful_auth sembra) e arrivati ​​a quel soluzione al login:

Given /^I am logged in with a new account$/ do 
    login = "test" 
    @current_user = User.new(
    :login => login, 
    :password => 'generic', 
    :password_confirmation => 'generic', 
    :email => "#{login}@example.com", 
    :state => "active" 
    ) 
    @current_user.save 
    x = User.find_by_login(login) 
    x.state = "active" 
    x.save! 

    visit "/login" 
    fill_in("login", :with => login) 
    fill_in("password", :with => 'generic') 
    click_button 
    response.body.should =~ /Logged in successfully/m 
end 

rendere modulare per più pulito corpus di test, questo è quello di demo il concetto che ho trovato.

5

jayzes ha condiviso i suoi esempi di passaggi test cetriolo utilizzando Rack :: Test :: Methods, JSONpath, Nokogiri ecc. Per scrivere test per API json/xml, è possibile che si desideri fare riferimento e creare altro per i propri passaggi.

https://github.com/jayzes/cucumber-api-steps

Problemi correlati