Adaptación de las Pruebas E2E para un Gran Proyecto

y hoy con mi colega Devesh, quiero presentarles la adaptación de las pruebas de extremo a extremo que hemos realizado para nuestro proyecto en Delivery Hero. El orden del día para hoy será el estudio de caso para las pruebas de extremo a extremo, o por qué comenzamos a hacerlo, la configuración de las pruebas de extremo a extremo, y las mejores prácticas que utilizamos, luego cómo evitar repetir este ciclo durante el desarrollo de las pruebas, y cómo estamos probando diferentes variaciones de la funcionalidad. Entonces, el estudio de caso para las pruebas de extremo a extremo fue bastante simple y común como para todos, porque Delivery Hero es una gran empresa con un gran proyecto de front-end, lleva mucho tiempo y esfuerzo mantenerlo y desarrollarlo, así que pensamos que es una gran mejora para la situación introducir las pruebas de extremo a extremo para no tener que probar manualmente las funcionalidades cada vez o depurar correcciones, así que podemos mejorar nuestra resistencia y la tranquilidad al implementar un gran cambio. Para tener una idea de la escala, tenemos más de 20 desarrolladores de front-end, hacemos 10 solicitudes de extracción diarias, nuestro repositorio de micro-front-ends tiene más de 50 mil líneas de código en total sin incluir los módulos de nodo, y el monolito tiene el antiguo monolito tiene 200 mil líneas de código en total, así que es bastante grande. La configuración de las pruebas de extremo a extremo que tenemos es básicamente un repositorio separado, porque agregamos las pruebas mientras nos estábamos migrando del antiguo proyecto al mono-repo con los micro-front-ends, y tenemos la simplicidad de ejecutar las pruebas en el repositorio separado para que los desarrolladores puedan incorporarse fácilmente. Por ahora, las ejecutamos como un trabajo programado, sí, sabemos que no es un estándar, digamos, pero estamos trabajando en la integración con los pipelines de CICD, y creamos nuestra propia integración personalizada de Slack con Cypress. Sabemos que hay un complemento oficial desarrollado la semana pasada, pero sí, todavía tenemos el nuestro por ahora. Sí, puedes ver el ejemplo de cómo es el mensaje del bot de Slack con el informe, y puedes hacer clic en el botón de informe y verificar este tipo de informe, que es muy útil porque muestra como la traza de la pila, el error exacto y la captura de pantalla. También, por supuesto, estamos utilizando algunas mejores prácticas del equipo de Cypress y algunas propias, que intentan utilizar los principios de accesibilidad en las pruebas creadas por Ken Dodds, el creador de la biblioteca de pruebas. En lugar de utilizar data CI, que es una mejor práctica del equipo de Cypress, podemos utilizar los atributos de área y otros atributos de accesibilidad, que son muy útiles y prácticos. También, por supuesto, utilizamos los comandos de Cypress para ayudantes generales, como si algo se utiliza en especificaciones separadas o más de dos veces, simplemente lo envolvemos en el comando y lo usamos como una sola línea, lo cual es más sencillo. Además, estamos utilizando una anotación de given, pero no solo como una estructura para la prueba, sino también, como un comando, porque como puedes ver aquí en un ejemplo, es muy útil, porque incluso si eliminas todo el código, aún tienes una idea de qué va a probar la prueba, porque a veces los comandos pueden ser complicados. Y ahora, quiero cederle la palabra a Dinesh, por favor. Gracias, Vadim. Hola a todos. Vadim mencionó escenarios bastante buenos sobre las mejores prácticas que estamos siguiendo. Así que, voy a guiarlos sobre dos cosas en particular que estamos haciendo en nuestro equipo, que realmente nos ayuda a lograr una prueba muy rápidamente. Entonces, una de estas cosas en particular es cómo evitar repetir el ciclo. Quiero decir, la mayoría de las pruebas de extremo a extremo que se ven hoy en día son como un flujo único. Primero, el usuario, quiero decir, primero la prueba de extremo a extremo pasa por una página, luego la segunda página y la tercera página. Es de manera secuencial. Pero considerando que somos un equipo de más de 20 desarrolladores, como mencionó Vadym, y diferentes equipos están trabajando en diferentes páginas o diferentes módulos, no queremos repetir todo el ciclo durante el desarrollo. Queremos probar nuestras funcionalidades, queremos probar solo nuestra página. Entonces, esto sería algo así, ¿de acuerdo? Ir directamente desde una página a nuestra página. Entonces, ¿cómo lo estamos logrando realmente? Creamos un servicio de utilidad en nuestras utilidades. Quiero decir, no es una utilidad, pero podríamos decir un comando que Vadym mencionó. Tenemos un comando personalizado, que es ir a la página. Entonces, ¿qué sucede en este comando en particular? Esto podría ser cualquier página. Como, esto podría ser ir a mi página y luego puedo marcar los datos anteriores sobre todas las páginas que vinieron antes, como todos los datos que agregaron al navegador, al almacenamiento, todo será

marcado aquí. Y lo que haré después de esto, usaré la ventana sin marcos. Configuraré el almacenamiento local, todos los datos, luego realizaré la prueba relacionada con mi página en particular. Y si algo está mal, como algo está mal durante la marcación de los datos, puedo simplemente evitar hacer la prueba y puedo redirigir a la página predeterminada. Ahora, lo que viene a continuación es, ¿cómo estamos probando realmente las diferentes versiones de una funcionalidad? Supongamos que estás en una página, tienes tu página, pero ahora quieres probar diferentes versiones de tu funcionalidad en esa página en particular. Entonces, ¿qué harías? Para esto, encontramos una solución simple, aprovechar las cookies del navegador. Creamos un servicio de utilidad en nuestra aplicación que utiliza las cookies del navegador y cambia los valores que provienen del servicio de banderas de funcionalidad y los fusiona con los nuevos valores. En este caso, este servicio de utilidad se puede utilizar para cambiar la variación de la bandera de funcionalidad y se ve así. En este caso, puedes ver que tenemos las banderas de funcionalidad que provienen del servicio, tenemos las banderas de las cookies, las fusionamos y las almacenamos en la memoria caché. ¿Y qué sucede después de eso? Ok. Nuestra aplicación está lista para manejar las cookies. Ahora solo necesitamos configurar esta clave en particular dentro de una cookie con las variaciones mencionadas aquí. Como puedes ver en la prueba, prueba para la variación de la bandera de funcionalidad, simplemente configuro la cookie para esas variaciones y luego, después de eso, puedo seguir escribiendo mi prueba. Como puedes ver, tenemos muchas buenas prácticas y tenemos cosas buenas implementadas en este momento, pero nadie es perfecto y siempre hay margen de mejora. Entonces, algunas cosas que notamos y tenemos un plan para ello. Una cosa es alejarnos del trabajo programado y agregar pruebas de extremo a extremo a un pipeline de CICD. Y lo siguiente es, como mencionó Vadim, tenemos las pruebas de extremo a extremo en un repositorio separado. Y tuvimos el caso de uso porque estamos migrando del monolito a un micro frontend. Una vez que todo se haya migrado al micro frontend, agregaremos las pruebas de extremo a extremo a nuestro monorepo para el micro frontend y definitivamente seguiremos mejorando. Eso es lo que estamos haciendo. Seguiremos mejorando la calidad de nuestras pruebas. Y por último pero no menos importante, por favor, únete a nosotros. Estamos buscando desarrolladores como tú, por favor únete a nosotros en Delivery Hero. Gracias. Gracias.