2012-04-15 6 views
7

Sto scrivendo una libreria per avvolgere le funzionalità di tsung in un modo che può essere meglio utilizzato dalle applicazioni rails. Voglio scrivere alcuni test di integrazione che si riducono a quanto segue:Avvio di un server Web all'interno di test ruby ​​

  1. lancio un semplice server web
  2. run Tsung-registratore tramite la libreria
  3. lancio selenio, con un profilo di Firefox configurato per utilizzare il Tsung proxy e ha questo prendere una pagina dal server lanciato nel passaggio 1
  4. esaminare la biblioteca registrata (esiste, è nella posizione corretta, ecc)

Per la fase 1, mentre ho potuto lanciare un Vanil app per la rotaia esterna (ad esempio, %x{rails s}), sono abbastanza sicuro che esiste un modo migliore per creare in modo programmatico un server Web semplice adatto per i test.

tl; dr - Qual è un modo per avviare un server Web semplice all'interno di un test?

+0

Basta usare Rack ?. –

+0

@NiklasB. Stavo pensando che avrebbe funzionato bene, ma non mi sto divertendo a trovare un esempio (i test in rack usano i mock da quello che posso dire). –

+0

Hm, sfortunatamente non posso indicarvi un esempio minimo, ma sono sicuro che capybara usa questo per le sue specifiche. Dai un'occhiata all'implementazione del server su https://github.com/jnicklas/capybara/blob/master/lib/capybara/server.rb e le specifiche su https://github.com/jnicklas/capybara/blob/master /spec/server_spec.rb, sono abbastanza istruttivi :) –

risposta

4

capibara utilizza un server rack ad-hoc per le sue specifiche:

qualsiasi applicazione Rack (comprese le applicazioni Rails) può essere servita con questo sistema, anche se la configurazione di Rails potrebbe risultare un po 'complicata.

+0

Ho usato il 'Timeout.timeout (60) {@ server_thread.join (0.1) fino a che non rispondevo? } 'pattern, e funziona benissimo! GRAZIE! –

9

È possibile eseguire il rollover del proprio server semplice. Ecco un rapido esempio utilizzando sottili e RSpec (quelle gemme, oltre a rack, deve essere installato):

# spec/support/test_server.rb 
require 'rubygems' 
require 'rack' 

module MyApp 
    module Test 
    class Server 
     def call(env) 
     @root = File.expand_path(File.dirname(__FILE__)) 
     path = Rack::Utils.unescape(env['PATH_INFO']) 
     path += 'index.html' if path == '/' 
     file = @root + "#{path}" 

     params = Rack::Utils.parse_nested_query(env['QUERY_STRING']) 

     if File.exists?(file) 
      [ 200, {"Content-Type" => "text/html"}, File.read(file) ] 
     else 
      [ 404, {'Content-Type' => 'text/plain'}, 'file not found' ] 
     end 
     end 
    end 
    end 
end 

Poi, nel tuo spec_helper:

# Include all files under spec/support 
Dir["./spec/support/**/*.rb"].each {|f| require f} 

# Start a local rack server to serve up test pages. 
@server_thread = Thread.new do 
    Rack::Handler::Thin.run MyApp::Test::Server.new, :Port => 9292 
end 
sleep(1) # wait a sec for the server to be booted 

Questo servirà tutti i file che si memorizza nel spec/support directory. Compreso se stesso. Per tutte le altre richieste restituirà un 404.

Questo è fondamentalmente ciò che capybara fa come menzionato nella risposta precedente, meno un sacco di raffinatezza.

+0

Qui potrebbe esserci un problema di sicurezza ... per sicurezza, cambierei File.exists? linea a: 'File.esiste? (file) && File.dirname (file) == @ root' – etipton

1

stub_server è un vero server di test in grado di offrire risposte predefinite ed è facile da avviare ... anche con il supporto di ssl.