Opciones para la prueba de pila completa en Ruby on Rails

Question

Hay un buen número de opciones para la prueba de Full-Stack de las aplicaciones Rails. Algunos usan navegadores reales, otros son sin cabeza, algunos no ejecutan javascript en absoluto.

¿Qué herramientas usa o recomienda y por qué?

Lista de simuladores navegador o automators:

• Carriles soporte integrado para pruebas de integración y funcionales (sin JS)
• Webrat
• Webrat :: selenio
• selenio
• Celeridad (a través de Culerity)
• Watir
• ...

Lista de DSL pruebas y marcos:

• Rails por defecto (afirmaciones, ...)
• Shoulda
• pepino
• Capybara (Unified DSL para varios simuladores de navegador)
• ...

Answer 1

He usado muchas cosas durante mi carrera en Rails en los últimos años.

Actualmente estamos trabajando en una aplicación de Rails bastante grande en JRuby con una cobertura de prueba muy sólida y nuestra pila se parece a la siguiente.

Unidad de Pruebas:

• cobertura RSpec de modelos, ayudantes, las bibliotecas y los controladores. la cobertura controlador tiende a ser muy alto nivel
• cobertura JSpec para un proyecto que está utilizando algún filo bonito JS y HTML 5 magia

Pruebas funcionales:

• pepino utilizando capibara y Culerity (que acaba de convertir desde WebRat con el fin de obtener cobertura de JS-pesada front-end de pepino)
• selenio que es ahora "legado" y poco a poco se está migrando a pepino/capibara

Answer 2

En el proyecto en el que estoy trabajando actualmente, para probar la pila completa usamos Cucumber con el carpincho como el controlador.

El front-end es muy javascript pesado, he probado un par de controladores de navegador sin cabeza (capybara-envjs y akephalos), pero ambos fallaron incorrectamente las pruebas que pasaron en un navegador real.

Answer 3

Estoy usando Cucumber + Capybara con una combinación de Selenium-webdriver y el controlador de prueba en rack. Capibara hace un buen trabajo al abstraer la diferencia entre las pruebas en el navegador que se manejan con selenium-webdriver para la prueba que realmente puede probar que el JavaScript funciona en un navegador, pero demora un poco para ejecutar y probar solo el HTML producido por el controlador/acción, que se ejecuta mucho más rápido pero no prueba JavaScript. Esto significa que el mismo conjunto de escenarios y definiciones de pasos se pueden ejecutar en un navegador o no sin tener que mantener conjuntos duplicados de definiciones de pasos.

Answer 4

Todas las aplicaciones de rieles se benefician de una buena cobertura de pruebas unitarias y funcionales, ya sea que use rspec o shoulda, etc., es principalmente una cuestión de preferencia personal. Soy fanático de shoulda principalmente por los bloques de contexto que proporciona, lo que hace que la configuración de escenarios de prueba sea mucho más fácil y clara de entender.

No creo que se necesiten simuladores/autómatas del navegador a menos que su aplicación sea bastante pesada. Yo recomendaría solo usarlos para probar javascript, y para ese propósito definitivamente es mejor usar un navegador real que simular. La aplicación en la que estoy trabajando ahora es muy pesada en javascript y estamos usando cucumber junto con watir/firewatir para ejecutar nuestras pruebas de pepino en Firefox para las funciones controladas por JavaScript en nuestro sitio.