javascript jquery ruby-on-rails continuous-integration integration-testing

Pruebas de integración de JavaScript en Ruby on Rails



jquery ruby-on-rails (4)

Busqué un poco para esto e intenté implementar una solución de fabricación propia, pero hasta ahora no he encontrado confianza en ella.

Lo que necesito es escribir pruebas de integración en Ruby on Rails que interactúen con JavaScript y obtener formas programáticas para afirmar algunos comportamientos. Estoy usando Test :: Unit para la parte de controladores / modelos, pero me cuesta probar algunos comportamientos jQuery / JavaScript utilizados por mi aplicación. Principalmente consiste en llamadas e interacciones ajax en la interfaz de usuario que actualiza algunos conjuntos de información.

No he encontrado una solución que me dé confianza y que se integre bien con el autotest y todo el proceso rojo-verde, por lo que, por ahora, la mayoría de las partes de mi código del lado del cliente no están probadas y eso me pone nervioso (como debería ser: P ).

Entonces, ¿alguien tiene sugerencias para las mejores prácticas sobre este tema? Las pruebas unitarias JS es un poco difícil, como señala Crockford, porque depende en gran medida del estado actual de la interfaz de usuario y etc., y como AFAIK aún no ha encontrado una buena manera de implementar pruebas decentes ...

En breve: necesito implementar pruebas para algunos comportamientos de la interfaz de usuario que dependen de Ajax, la integración con el autotest o alguna otra herramienta de CI y no he encontrado una forma buena y elegante de hacerlo.

Gracias a todos por la atención, Saludos cordiales.


AFAIK, aparte de una combinación de Capybara con Selenium Web-Driver, hay muy pocas opciones para realizar pruebas automatizadas del código JS. Uso pepino con capybara y selenio web-driver y como Selenium-webdriver realmente ejecuta Firefox o Chrome para probar una página en particular con Ajax Call, toma mucho más tiempo ejecutar una serie de pruebas.

Hay algunas alternativas pero no funcionan todo el tiempo o para cada situación. Por ejemplo: Capibara con envjs.


En abril de 2011, los chicos de thoughtbot actualizaron su búsqueda de pruebas de javascript. Akephalos ha caído en desgracia por las siguientes razones:

Errores: como se mencionó anteriormente, hay errores en htmlunit, específicamente con jQuery en vivo. Aunque todas las implementaciones del navegador tienen errores, es más útil si las pruebas experimentan los mismos errores que los navegadores reales.

Compatibilidad: htmlunit no implementa completamente el conjunto de características que hacen los navegadores modernos. Por ejemplo, no maneja completamente los rangos de DOM o las cargas de archivos Ajax.

Representación: htmlunit en realidad no representa la página, por lo que las pruebas que dependen de la visibilidad o el posicionamiento de CSS no funcionarán.

Rendimiento: cuando la mayoría de las pruebas usan Javascript, las suites de prueba con htmlunit comienzan a rastrearse. Se necesita un tiempo para iniciar una prueba con Akephalos, y un conjunto de pruebas grande puede tomar fácilmente 10 o 15 minutos.

Así que lanzaron su propia solución, que es de código abierto: capybara-webkit . Todavía es bastante nuevo, pero parece ser el camino a seguir ahora.



He usado pepino y capibara con selenio. Esto fue muy frustrante porque el selenio no parecía poder ver un javascript generado dinámicamente, a pesar del hecho de que se suponía que el capibara lo estaba esperando. Eso fue en enero de 2011. Las cosas pueden ser diferentes ahora.

Actualmente, estoy usando pepino y capibara con akephalos. Hasta ahora, ha sido muy difícil porque 1. no tiene cabeza, por lo que no puede ver el progreso. La llamada "save_and_open" de Capybara ha ayudado hasta cierto punto. 2. jQuery y akephalos no parecen jugar muy bien juntos. Por ejemplo, activar un botón de radio con jquery .change () funciona bien en Chrome, pero no en akephalos. Tal vez esto sea intencional porque más tarde escuché en algún lugar que no funciona en IE. Solucioné el problema utilizando .click () en lugar de .change () para el botón de radio, pero como la función .change estaba configurada para ejecutarse en un montón de preguntas, tuve que codificar específicamente para que funcionara para la prueba .

El resultado final para mí es que las pruebas automatizadas de aceptación de javascript en un riel env todavía son inmaduras y posiblemente más trabajo que vale la pena.