2011-06-30 14 views
42

Tengo una aplicación que usa subdominios para cambiar bases de datos (multi-tenancy). Intento usar Capybara para las pruebas de integración, y realmente depende mucho de los subdominios.Carpincho con subdominios - default_host

Según entendí, la configuración de Capybara.default_host= haría que todas mis solicitudes provinieran de este host. Esto no parece ser el caso. En this post, el autor recomienda simplemente visitar la URL explícita con un host, pero esto se vuelve un poco molesto si estoy navegando por todos lados. Me gustaría simplemente configurar el host, luego poder usar mis rutas de los raíles como se esperaba. No está seguro de lo que estoy haciendo mal, pero aquí es lo que he intentado:

# spec_helper.rb 
RSpec.configure do |config| 
    config.before(:each, :type => :request) do 
    Capybara.default_host = 'http://app.mydomain.com' 
    end 
end 

# in some_integration_spec.rb 
before do 
    puts "Capybara.default_host: #{Capybara.default_host}" 
    puts "some_app_url: #{some_app_url}" 
end 

Esto produce la salida:

Capybara.default_host: http://app.mydomain.com 
some_app_url: http://www.example.com/some_path 

¿Qué estoy haciendo mal? default_host parece no hacer nada. Como digo, no quiero tener que decir visit(Capybara.default_host + some_app_path) ya que es un poco molesto cada vez. ¿Por qué más existe esta opción default_host?

+0

Tal vez podría ser útil a alguien [mi respuesta a esta pregunta] (http://stackoverflow.com/a/18476731/895789) –

Respuesta

56

No estoy seguro del uso previsto de default_host, pero app_host hace lo que necesita. Descubrí que primero necesito llamar al método de sesión de rieles host! para establecer la cadena de host que se pasará a los controladores en el objeto de solicitud.

Luego debe configurar Capybara.app_host para decirle a Capybara que llame a su aplicación a través del servidor web en lugar de simplemente hacer las llamadas en curso. Si no haces eso, el carpincho se agita cuando encuentra redirecciones y descarta la información del host en la segunda solicitud.

No estoy seguro de por qué esto no soluciona el problema de los Rails request automáticamente, pero he encontrado que a menos que establezca el host en ambos lugares explícitamente, entonces obtengo resultados inconsistentes.

def set_host (host) 
    host! host 
    Capybara.app_host = "http://" + host 
end 

before(:each) do 
    set_host "lvh.me:3000" 
end 

Luego puede usar rutas relativas para acceder a las páginas.

Actualización:

Carpincho 2.x y rspec-carriles 2.12.0 introducidas especificaciones "característica" para la ejecución de pruebas de aceptación de carpincho. El nuevo módulo en rspec-rails es diferente de RequestExampleGroup y ya no tiene acceso al método host! de prueba en bastidor. Ahora usted quiera usar default_url_options lugar:

def set_host (host) 
    # host! host 
    default_url_options[:host] = host 
    Capybara.app_host = "http://" + host 
end 
+0

interesante ... echaré un vistazo a esto cuando tenga la oportunidad. ¡Gracias! – brad

+0

parece que app_host es el ganador, ojalá los documentos fueran más claros en cuanto a la diferencia, ¡gracias! – brad

+4

Esto funciona perfectamente. Además, si está utilizando un dominio público como 'lvh.me', puede configurar el puerto automáticamente usando' Capybara.server_port = 31234', y luego 'set_host" lvh.me:31234 "' – alf

0

Esto no es exactamente la misma situación como usted, pero esto podría ayudar a algunas personas:

Para mi proyecto actual, estoy usando pow con muchos subdominios. El conjunto de pruebas también debe ejecutarse en un puerto diferente.

La solución depende de la versión de carpincho que esté ejecutando.

Para la última versión actual Pongo esto en custom_env.rb:

Capybara.server_host = 'myapp.dev' 
Capybara.server_port = 9887 
Capybara.run_server = true 

# I don't remember what this was for. Another team member wrote this part... 
module ActionDispatch 
    module Integration #:nodoc: 
    class Session 
     def host 
     [Capybara.server_host, Capybara.server_port].join(':') 
     end 
    end 
    end 
end 

Con capibara 1.1.2, que había tenido que hacer el cambio anterior, pero se convierte en server_hostapp_host y modificar lib/capibara/servidor. RB en la joya como esta:

def url(path) 
    .. 
    if path =~ /^http/ 
    path 
    else 
    # Was this (Capybara.app_host || "http://#{host}:#{port}") + path.to_s 
    (Capybara.app_host || "http://#{host}") + ":#{port}" + path.to_s 
    end 
end 
29

Cuando es necesario cambiar la dirección URL para incluir el subdominio, puede especificar el app_host en las definiciones de paso. Utilizar un dominio como lvh.me ya que apunta a 127.0.0.1:

Capybara.app_host = "http://#{subdomain}.lvh.me" 

Carpincho asume que cuando se está especificando una app_host que se está probando un servidor remoto que se ejecuta en el puerto 80, pero en nuestro caso, estamos probando una aplicación local que se ejecuta en un puerto aleatorio especificado por Capybara. Para solucionar este problema, en el archivo de env.rb, añada esta línea:

Capybara.always_include_port = true 

Ahora, cuando usted visita una página de su aplicación ...

visit '/page' 

... la url especificará el subdominio, así como el puerto en el que se ejecuta la aplicación.

FYI: Esto funcionó para mí usando Capybara 2.0.2.

+2

Este método también funciona para mí y ninguno de los otros métodos funciona. Estoy en Capibara 2.4.3. Para mi aplicación, también quiero saber el número de puerto que fue seleccionado por Capybara, dentro de mi entorno de prueba. Estoy usando Poltergeist/PhantomJS, y puedo obtener esa información de esta llamada: '' 'Capybara.current_session.server.port''' –

0

partir de:

  • capibara (2.4.1)
  • capibara-webkit (1.3.0)

    Capybara.server_host = "example.com" 
    Capybara.server_port = 3050 
    Capybara.run_server = true 
    Capybara.javascript_driver = :webkit #requires capybara-webkit 
    
+0

Esto parece ser un error, ya que la versión más reciente de capybara es 2.13.0 . – Siraris

Cuestiones relacionadas