Growing pains: Garantizando la calidad - Web UI Testing

Esta nota es la cuarta parte de nuestra serie “Growing Pains” que describe los obstáculos que nos fuimos encontrando al crecer y como los fuimos superando. ¡Lee nuestra historia!

Ya habiendo definido una nueva arquitectura Web para permitir independencia entre los distintos equipos de desarrollo, ahora teníamos el desafío de avanzar a partir el monolito en micrositios. Dada la complejidad asociada de dicha tarea, nos propusimos construir un framework de test UI que valide los distintos flujos, cada vez que se realice un cambio.

En nuestra propuesta, nos imaginamos qué nos gustaría que tuviera ese flujo y del intercambio con los equipos surgieron los siguientes ideas:

1. La ejecución de los tests debía estar asociada a los Pull Requests (PR) de cada equipo, para tener trazabilidad.
2. El resultado de la ejecución de los tests debía quedar asociado al Pull Request.
3. Se debía poder obtener evidencia (capturas de pantallas o video) de manera automática que permitiera fácilmente entender qué falló y qué funcionó.
4. La ejecución de los tests debía ser rápida.
5. El nombre de la solución debía seguir la temática Marvel que ya establecimos para Jarvis 🙂.

Es así como nace F.R.I.D.A.Y., nuestro Bot que escucha atentamente lo que pasa en nuestros repositorios de Github para asistir en cualquier tarea que necesitemos, en particular para este caso, validar los cambios antes de aceptarlos.

Entendiendo el flujo de tests UI

Para poner contexto y aclarar conceptos, veamos el siguiente diagrama

Todo comienza con la creación de un Pull Request en Github, donde el/la desarrollador/a escribe como un comentario mas “Check PR” para darle comienzo a la ejecución de los tests UI.

A partir de ahí, nuestro Bot F.R.I.D.A.Y. que se encuentra atento a los comentarios en los PRs, lanza un job en Jenkins donde realiza un checkout de la rama del PR, build de la aplicación y comienza a correr los tests de UI.

Al finalizar la ejecución, el detalle de la misma es informada al dashboard Sorry-Cypress y en el mismo PR se informa el resultado final de la ejecución con links a la información detallada de cómo salieron los tests.

De esta manera se busca darle a las/los desarrolladoras/es la posibilidad de gestionar la ejecución de sus tests desde un único lugar -GitHub- simplificando el proceso y evitando el cambio de contexto entre distintas herramientas o plataformas.

La elección del framework de Test UI

Dentro de las opciones que evaluamos se encontraban Selenium, Nightwatch y Cypress, eligiendo esta última por las siguientes razones:

1. Velocidad de ejecución de los tests, soportando paralelismo.
2. Sencillo de implementar.
3. Comunidad muy activa.
4. Facilidad de integración en entornos de integración continua.
5. Conexión con dashboard de resultados muy amigable

Dado que cada framework posee también sus desventajas, las correspondientes a cypress son:

1. No permite el manejo de pestañas o tabs.
2. Limitado en cuanto acciones muy específicas como mouseover.
3. Puede resultar difícil al comienzo para personas que no están tan familiarizadas con el lenguaje de programación JavaScript

Estas desventajas no resultaron decisivas al momento de seleccionar el framework a utilizar, dada la arquitectura y funcionamiento de la aplicación no impactaron en el resultado.

Retomando las ventajas, “Conexión con dashboard de resultados muy amigable”, Cypress ofrece a través de su sitio una integración a su dashboard mediante distintos planes pagos que se ajustan a la posibles necesidades pero en cambio, nosotros decidimos implementar el proyecto Sorry-Cypress Dashboard on-premise (en AWS).

En pocas palabras Sorry Cypress es un dashboard minimalista, open source y fácilmente deployable en la nube que permite registrar toda la información relacionada a la ejecución de las pruebas.

En la imagen a continuación podemos ver una ejecución de un conjunto de tests, su estado global, información de cada test, tiempo de ejecución y toda la información de quién ejecutó los mismos

A su vez, accediendo a cada test es posible acceder al video que muestra en detalle cómo se ejecutó el test, facilitando encontrar posibles errores en caso de que ocurran.

Conclusión

En un escenario de cambios sobre cualquier plataforma, poder validar rápidamente los distintos flujos para avanzar más rápidamente resultaba clave.

La incorporación de Cypress mas un dashboard que nuclee toda la información de cada ejecución, permite a los equipos conocer el estado de las múltiples ejecuciones y asegurar que la plataforma se mantiene consistente a medida que se van sumando cambios.

Finalmente, nos encanta intercambiar ideas y conocer otras iniciativas, por lo que si quieres más detalles, no dudes en dejarnos preguntas o contarnos sobre otras implementaciones que estés llevando adelante, vía twitter @PeYaTech.

¡Gracias a todos los que ayudaron a crear este artículo! Javier Barboza, Darian Campos y Leonel Corso.