2011-04-13 15 views
15

En primer lugar, la configuración ...¿Cuál es la mejor forma de probar el humo de un entorno de producción/producción en Rails?

Actualmente estoy desarrollando una aplicación Rails 3 en Mac OS X usando Ruby 1.8.7 MRI, ejecutando pruebas y desarrollo local contra una base de datos MySQL. Tengo 3 "otros" entornos no locales que utilizamos en mi empresa para cada aplicación llamada dev, tqa y prod. Se ejecutan en Tomcat utilizando JRuby (1.8.7) con Oracle como back-end.

Como puede ver, los entornos son bastante diferentes, y hemos encontrado algunos errores en la implementación en un entorno Oracle/JRuby que no existe localmente (como el manejo de fechas y la especificación de esquemas predeterminados en Oracle).

Me encanta ejecutar algo como Cucumber/Webrat/Capybara a nivel local para golpear cada URL expuesta en la aplicación para asegurarme de que las cosas básicas funcionen (es decir, una prueba de humo). Lo ideal es que acceda a todas las direcciones URL y haga algunas cosas simples como ingresar datos en formularios y hacer clic en botones, etc.

Idealmente, cuando implemente en dev/tqa, ejecutaría algo similar, excepto que apuntaba al desplegado aplicación en lugar de la aplicación local. Pepino parece optimizado para golpear una aplicación que se ejecuta localmente y se integra bien con Rails, pero no puede ejecutarse contra lo que es a todos los efectos una aplicación "externa" (o al menos no puedo encontrar una manera fácil que realmente funcione).

Además, cuando implemente para pinchar me gustaría un conjunto similar de pruebas de humo para ejecutar, excepto que no cambiaría el estado de la base de datos de producción actual (es decir, solo OBTUVE URL).

Algo como Selenium podría usarse, supongo, pero me gustaría simplemente ejecutar una tarea de rake y obtener los resultados como lo hago con Cucumber.

¿Hay alguna forma de Rails/Ruby para hacer esto, o todos los demás simplemente lanzan su propia solución usando wget o Selenium?

Una pregunta similar se le pidió aquí: Automatically smoke test all webpages in application, after deployment

No estoy seguro de que la pregunta es exactamente lo que tengo en mente, sin embargo.

Respuesta

6

Sí, puede escribir pruebas de humo con Cucumber and Capybara y ejecutarlas en servidores remotos. Lo hice y funciona.También hice curl/wget y similares en algunos proyectos, pero Cucumber + Capybara te permite interactuar con páginas (incluso las que usan Javascript), no solo rasparlas.

  • El controlador de Capybara Rack::Test no admite solicitudes remotas; sus controladores Javascript lo hacen. Ya sea que realmente necesite Javascript para trabajar en las páginas que está probando, necesitará usar un controlador de Javascript. Configure Capybara para usar un controlador de Javascript de acuerdo con los documentos del controlador y etiquete sus pruebas @javascript. (Recomiendo el driver poltergeist/PhantomJS, es más rápido que Selenium, da mejores errores que capybara-webkit, y es fácil de configurar). Puedes hacer cosas en tus pruebas que necesitan Javascript, y serás fumador. probando toda tu pila incluyendo Javascript.
  • Escriba sus pruebas para que no necesiten limpiarlas o hacerlo de manera segura en una base de datos de producción. No pueden usar DatabaseCleaner. (Para evitar accidentes, coloque las pruebas en su propio proyecto con un Gemfile que no contenga DatabaseCleaner). Dado que las pruebas de humo se ejecutarán contra un servidor remoto y, por lo tanto, no pueden usar transacciones para limpiar, tampoco deben modificar la base de datos o debe eliminar específicamente solo los objetos que crean.
  • Establecer Capybara.app_host = "http://your-server.yourco.com"
  • Establecer Capybara.run_server = false (no es necesario, pero no tiene sentido que ejecuta un servidor local que no usará)
  • Si las pruebas modifican la base de datos, definir el entorno de base de datos de prueba para el medio ambiente que desea prueba de humo.
  • Implementar y probar.
5

Una forma de simplemente golpear en su aplicación para ver si explota es obtener una lista de solicitudes GET de su servidor de producción y registrarlas en un programa como curl o wget que las recuperará rápidamente. como sea posible.

Aquí está un ejemplo sencillo:

#!/usr/bin/env ruby 
# rerun 

require 'uri' 

def extract_from_log(base_uri, log_path) 
    File.open(log_path) do |log| 
    while (line = log.gets) 
     if (line.match(%r{"GET (/\S+) HTTP/\d\.\d"})) 
     uri = URI.join(base_uri, $1) 
     puts uri.to_s 
     end 
    end 
    end 
end 

base_uri, log_path = ARGV 

if (base_uri and log_path) 
    extract_from_log(ARGV[0], ARGV[1]) 
else 
    puts "Usage: #{File.basename($0)} <base_uri> <log_path>" 
    exit(-1) 
end 

Dado un archivo de registro web estándar con líneas de juego "GET /... HTTP/1.1" se puede extraer fácilmente los caminos, pero es necesario proporcionar la base URI:

rerun http://example.com/ example.log 

Este listará todas las URL encontradas en ese archivo de registro. Puede canalizar esto a wget con fines de ir a buscar:

rerun http://example.com/ example.log | wget -i - 

Si usted ha roto nada, que comienza a recibir los errores en su aplicación, y con un sistema de notificación apropiada podrás atrapar a estos y pista ellos abajo.

Cuestiones relacionadas