02 - ¿Cómo hacemos pruebas automatizadas de Cypress en nuestra interfaz?

Iniciado por Mr. Bones, Agosto 30, 2023, 04:28:13 PM

Tema anterior - Siguiente tema

0 Miembros y 1 Visitante están viendo este tema.

Agosto 30, 2023, 04:28:13 PM Ultima modificación: Septiembre 08, 2023, 03:42:33 PM por Mr. Bones
⭐Cómo hacemos pruebas automatizadas en nuestra interfaz⭐

Y Arrancamos...

    Nuestra arquitectura front-end se basa en el enfoque BFF utilizando Node + React, que combina la velocidad de JavaScript y utiliza nuevas formas de representar sitios web, haciéndolos altamente dinámicos y receptivos para los usuarios. Para ello hacemos uso de GraphQL para solicitar datos al backend.
 
GraphQL se desarrolló para hacer frente a la necesidad de mayor flexibilidad y eficiencia que experimentan los desarrolladores al interactuar con las API REST, lo que hace que el flujo de trabajo sea mucho más eficiente.




La herramienta de prueba

Hace un tiempo decidimos empezar a utilizar Cypress, una herramienta que pretende superar a Selenium (o hacerte olvidarlo de inmediato), eliminando todos sus inconvenientes, como la configuración y la depuración. Si quieres profundizar en esta comparativa, aquí puedes leer más.



Cypress es una herramienta de prueba creada para la web moderna. Se pueden ver muchas similitudes entre ellos, pero los beneficios y limitaciones que enfrentará son bastante diferentes dependiendo de cuál utilice. Si lo que busca es facilidad de configuración y depuración, Cypress puede ser una buena opción.

Cypress es un operador de pruebas de código abierto que le permite escribir pruebas en código JavaScript. Puede consultar su repositorio y contribuir a su misión si así lo desea.

En mi caso, cambié de Selenium a Cypress por varias razones. El más importante es que parecía bastante fácil de configurar y trabajar con él, y eso nos permitió desde el control de calidad escalar los esfuerzos de prueba al difundir su uso entre los controles de calidad y los desarrolladores. Dado que utiliza JavaScript, nuestro equipo de desarrollo lo acogió con agrado y comenzó a usarlo casi sin fricciones o básicamente porque no me gusta Java.


La tecnología subyacente

Cypress está escrito en JavaScript y te permite escribir pruebas en JavaScript. Una cosa a tener en cuenta es que este framework está construido sobre Mocha, por lo que, si ya está acostumbrado a escribir scripts de prueba utilizando Mocha como marco de prueba, es probable que encuentre algunos viejos amigos aquí.

Cypress adopta de Mocha su sintaxis BDD que encaja muy bien tanto con la integración como con las pruebas unitarias. Otras tecnologías incluidas con Cypress son Chai, Chai-jQuery, Sinon y Sinon-Chai.


Ejecutando las pruebas

Al ejecutar la prueba en modo GUI, vemos lo siguiente:



Lo que hace Cypress es abrir un navegador, luego a la izquierda ves el 'registro en vivo' que refleja todo lo que hace el navegador durante la prueba, y a la derecha tienes la aplicación bajo prueba.

Vale la pena mencionar aquí que Cypress no es una herramienta externa que se comunica con el navegador a través de una API, sino que se ejecuta directamente en el navegador, y esto hace que esté tan cerca de la aplicación web bajo prueba que puedes hacer cosas que quieras.

Una de las características clave aquí es la capacidad de depuración. Cuando la prueba finaliza o falla, el estado no se restablece, lo que significa que puede desplazarse por el 'registro en vivo' para ver qué o dónde estaba haciendo Cypress en ese momento; se muestra una captura de pantalla para ese momento para cada acción. Incluso puede abrir la consola del navegador y obtener una descripción completa de los pasos que seleccione en el registro. Esta característica ha impulsado tanto todo el proceso de desarrollo de pruebas que ahora no podemos prescindir de ella.


Configurando el CI

Para nuestro sistema de CI utilizamos Brigade, que es una herramienta basada en eventos para ejecutar tareas automatizadas en la nube. Nuestros colegas del equipo de DevOps escribieron una serie de publicaciones sobre cómo funciona esto, por lo que, en caso de que esté interesado, puede profundizar aquí.

Como se comentó al principio del post, dividimos nuestra aplicación en diferentes BFF, lo que nos permite construirlas e implementarlas de forma independiente, lo que hace que el proceso de lanzamiento sea más rápido y fácil de escalar.

Todos estos BFF tienen al menos un repositorio de prueba e2e adjunto, que se activará como un evento diferente cada vez que se fusione una solicitud de extracción.




Este caso anterior ilustra la serie típica de eventos que ocurren al fusionar una nueva solicitud de extracción en nuestro entorno de prueba: canalización BFF. Primero viene el evento push (incluidas las pruebas unitarias  8) ), luego la implementación en el entorno de prueba y, finalmente, un post_deploy_hook activa las pruebas e2e configuradas. Tenemos Slack integrado en este bucle para notificarnos de cada paso y advertirnos en caso de que algo salga mal.

Las pruebas e2e se almacenan en un repositorio propio (que representan más de 15 repositorios). Enviamos todos los cambios en el código de prueba de e2e a esos repositorios para crear una nueva imagen de Docker que el BFF tomará y ejecutará cada vez que llegue el evento.

Centrándonos en el evento de prueba e2e, el comando que utilizamos para ejecutar las pruebas es:


$ cypress run --record --group 4x-electron --parallel --ci-build-id ${buildId}

Analizando brevemente los parámetros:

  • grabar: envía las grabaciones de video a Cypress Dashboard para realizar un seguimiento de las ejecuciones
  • grupo: Agrupa las pruebas grabadas juntas en una sola ejecución.
  • paralelo: Permite la paralelización de las pruebas.
  • buildId: necesario para definir una compilación o ejecución única

Panel de control de cypress

La última parte del viaje. Cypress Dashboard es un servicio que nos permite acceder a pruebas grabadas, siendo bastante útil cuando las ejecutamos en el CI. Nos brinda información sobre todas las ejecuciones de prueba activadas, incluidos registros, capturas de pantalla y videos.



Aunque podríamos prescindir del Panel, lo encontramos bastante útil y lo utilizamos ampliamente; tenemos un plan pago que permite que varios de nuestros ingenieros tengan acceso a él y trabajen de una manera más eficiente.

La gran ventaja aquí es que podemos conocer el estado de la aplicación con bastante rapidez y podemos abordar cualquier problema de inmediato cuando algo falla. Una vez que se revela la falla y se calcula el impacto potencial, solucionamos el problema y lo probamos nuevamente lo antes posible o posponemos la afirmación fallida hasta que se solucione, para no introducir ruido en el proyecto.
Mr. Bones