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á
Comments