Cypress: ¿Qué es? ¿Por qué y cómo lo usamos en Get on Board?

La suite de test que llegó para quedarse.

Photo by Hack Capital on Unsplash

Pruebas end to end, pruebas de integración, pruebas unitarias ¿Te suena familiar? Si no es así, no te sientas mal, estas frases también eran completamente desconocidas para mí hace no mucho. De hecho, escribir las pruebas para cualquier cosa que estuviese desarrollando significaba más un castigo que algo que me salvaría de algún inconveniente.

Al ir haciendo del desarrollo guiado por pruebas una práctica continua, me fui sintiendo más cómoda con probar mis aplicaciones y conocer Cypress cambió por completo las reglas del juego.

¿Qué es Cypress?

Según su página oficial, Cypress es una herramienta de testing de última generación construida para la web moderna.

Esta nos permite escribir todo tipo de tests: End to end, de integración, unitarios, en fin, Cypress puede probar cualquier cosa que funcione en un navegador.

Además, parte de su misión puede conectar inmensamente con cualquiera que desarrolle con un poquito de experiencia y es que en Cypress afirman que:

Queremos ayudar a los desarrolladores a construir una nueva generación de aplicaciones modernas más rápidas, mejores y sin el estrés y la ansiedad asociados con el manejo de las pruebas.

Y sé que no soy la única que ha sentido ese estrés y ansiedad cuando los tests fallan antes de hacer un push.

¿Por qué lo usamos?

En Get on Board, nos dimos cuenta de que este sentimiento era algo que sucedía muy seguido en el dev team, y fue cuando decidimos hacer el cambio. Antes de mi llegada, uno de los dolores de cabeza más grande que existía era el de los tests. Test que no corrían o pasaban aleatoriamente escritos en Rspec, nos daban una sensación de falsa seguridad e incertidumbre al momento de realizar nuestros pull requests.

Fue así como se tomo la decisión de incursionar en el maravilloso pero aún desconocido mundo de Cypress.

Para los test unitarios, hemos estado utilizando Jest, específicamente con nuestros componentes de React. Sin embargo, nos estaba faltando hacer pruebas end-to-end, que son las que permiten replicar el comportamiento del usuario en la aplicación y verificar que todo funciona como debe ser, y con Cypress empezamos a hacerlo escribiendo código Javascript bastante sencillo, que no por eso resultar ser menos poderoso.

Cypress usa las aserciones de Chai y Mocha.js, cuenta con una interfaz gráfica que te muestra el proceso como lo realizaría un usuario desde su computadora, y mientras corren los test, te permite obtener insights de todo lo que ocurre, además de poder interactuar y detenerte para ver el por qué de las fallas, regresar a cada paso realizado durante la ejecución para ver como era la UI en ese punto del tiempo, ver elementos en consola, y otras maravillas.

Además, ayudándonos de librerías como testing library logramos aumentar su potencialidad y alcance. Veamos el siguiente ejemplo:

Esperamos que esta interfaz tenga el logo de Get on Board, que muestre un mensaje con un saludo la primera vez que se da click al botón verde y que si se vuelve a dar click al mismo botón, este cambie a rojo y muestre un mensaje que te indique detenerte.

Para probarla podemos usar este código:

Y al correr en nuestra consola:

npm run cypress:open

Observamos como el test se ejecuta de esta manera:

Aquí podemos ver como obtiene cada elemento según lo especificado en el test y hasta recrea las animaciones de nuestra interfaz al seleccionar ese elemento. Genial, ¿no?

¿Y cómo lo usamos?

Nuestra plataforma cuenta con dos interfaces de usuario (profesional y empresa). Y fue por esta última donde empezamos a realizar los tests. Cuando probamos el flujo, nos dimos cuenta que la data generada por cada test, era guardada en el siguiente que se corriera, haciendo que la ejecución de una prueba se viese afectada por la ejecución de otra.

Para solucionar este problema, creamos un API endpoint, escribiendo código con Ruby que está habilitado solo en el entorno que hicimos para correr Cypress. Con este, generamos una base de datos a la cual hacemos reset y añadimos data antes de ejecutar cada test.

Agregamos este código a nuestra configuración de Cypress:

Y de este modo, nos cercioramos de que la data generada por cada test se borre antes de correr el siguiente y hacemos que cada test esté aislado del resto.

¿Qué sigue?

Para nosotros, sin duda Cypress ha sido esa herramienta que llego para quedarse, nos ha aliviado un gran dolor y esperamos que al integrarlo a nuestro pipeline, podamos evitar por completo cualquier equivocación que como seres humanos no estamos exentos a cometer.

Y tú ¿Cómo escribes tus test? ¿Ya has usado Cypress? Cuéntanos tu experiencia en los comentarios. También estamos abiertos a leer cualquier sugerencia, comentala o envia un correo a team@getonbrd.com 🤗.