Monitoreo Sintético y Pruebas e2e: Dos Caras de la Misma Moneda

Hola, TestJS Summit. Es genial verlos a todos. Mi nombre es Carly Richmond. Soy una desarrolladora senior en Elastic. Y estoy aquí hoy para hablar sobre testing, lo que probablemente esperaban de una conferencia de testing, seamos honestos. Pero, ¿esperaban que hablara también sobre monitoreo? Posiblemente no. Así que hoy voy a aprovechar mi experiencia previa como ingeniera de software para hablar sobre las pruebas de extremo a extremo y el monitoreo sintético. Hablaré sobre cómo, a pesar de nuestros pensamientos, en realidad, estos elementos son dos caras de la misma moneda. Y también mostraré un ejemplo en el que tomamos un marco de pruebas de extremo a extremo, en este caso, y lo combinamos con GitHub actions para CI y luego monitoreo utilizando Elastic Synthetics para mostrar cómo podemos usar los mismos scripts para ambas pruebas de extremo a extremo y monitoreo sintético.

Pero antes de todo eso, necesitamos hablar sobre la noción de desplazamiento a la izquierda porque eso es imperativo para entender este argumento. Así que para mí, desplazarse a la izquierda era algo que realmente tenía mucho sentido. Tratar de detectar defectos más temprano en el ciclo. Y también tenía sentido para mí porque, en realidad, les contaré un pequeño secreto, solía ser más que solo un ingeniero. En mi primer rol como ingeniero de software, también tuve que hacer todo lo demás. Tuve que hacer gestión de producción, tuve que lidiar con problemas de usuarios, y dado que era un sistema regulatorio, siempre se requería una respuesta bastante rápida para esos casos. Y también nos ocupamos de la implementación, testing, y coordinación del testing de usuarios. Hicimos todo en esa aplicación debido al tamaño del equipo y la experiencia que teníamos. Y fue realmente cuando comenzamos a intentar transferir algunas de las responsabilidades de soporte a un equipo de gestión de producción dedicado que me di cuenta de que estas actividades son más comúnmente realizadas por diferentes grupos. Pero mi experiencia con eso fue realmente mi idea inicial sobre por qué DevOps tiene sentido, porque estábamos trabajando juntos. Ellos configuraron el sistema de tickets, por ejemplo. Trabajé con ellos para documentar todo el conocimiento, sacarlo de mi cabeza, para que las personas pudieran react a los problemas e intentar ayudar a los usuarios donde pudieran. Y luego, si intentaban solucionar un problema y no funcionaba del todo, ellos me llamaban para ayudar y actualizábamos el artículo de conocimiento con la información adicional. Pero también aprendí de ellos porque hablamos sobre testing, hablamos sobre cómo podríamos hacer que la aplicación fuera más fácil de monitorear. Todas estas cosas que realmente como desarrollador no tienes mucha exposición y tuve mucha suerte por eso. Y pensé que era normal hasta que me mudé a mi primer trabajo de desarrollo web y me di cuenta de que eso es en realidad una experiencia muy rara. E incluso hablando con ingenieros de devops y SREs ahora, veo que en realidad la relación a pesar de la aparición de devops es más parecida a un juego de roca. Y tenemos que hablar sobre por qué esto es así. La primera razón es la empatía. No somos buenos para empatizar con los otros lados dentro de esta ecuación. Los desarrolladores no empatizan bien y colaboran con los testers a quienes sienten que podrían estar devolviéndoles características que pensaban que eran perfectas. La gestión de producción está recibiendo regularmente nuevas características que se construyen en pequeños incrementos que significan que a menudo están sobrecargados con características de las que no saben mucho. Y todo el mundo simplemente siente que el otro lado realmente no entiende cuál es su papel y qué están tratando de hacer. La otra cosa es la falta de prioridad común. Este letrero aquí en el asiento todos más o menos sabemos lo que esto significa. Está muy claro para quién está destinado este asiento. Pero si pensamos en la priorización del backlog dentro del mundo ágil reciente no siempre es tan claro como eso y mi experiencia de trabajar con propietarios de productos fue a menudo que las nuevas características se priorizaban regularmente sobre pequeñas mejoras de toil, adiciones como capacidades de monitoreo mejoradas e incluso a veces las correcciones de errores menores se ponían al final del backlog en comparación con nuevas características que ellos podían entender. Y el último problema que vi fue que a menudo nuestros conjuntos de herramientas son tan dispares que es muy difícil averiguar si hay algún terreno común entre nosotros. Y el monitoreo sintético en las pruebas de extremo a extremo es el ejemplo principal de eso. Así que las pruebas para cualquiera que no esté familiarizado son básicamente pruebas que te permiten probar

La otra cosa es el monitoreo sintético, que es más del lado de las cosas de SRE. Y el monitoreo sintético se refiere a la capacidad de, en un horario regular, ejecutar scripts contra una aplicación en particular para validar que está activa y viva. Y esto puede ser tan simple como un simple ping en un endpoint para asegurarse de que un servicio de salud está activo hasta algo tan complicado como simular clics de usuario y acción para asegurarse de que la aplicación es receptiva para los usuarios que van a entrar y usar la aplicación. Y probablemente ya has adivinado lo que es común entre ambas cosas es, de hecho, la perspectiva del usuario.

Pero estas cosas a menudo son construidas por diferentes audiencias, desarrolladores y testers, en comparación con SREs e individuos de gestión de producción. Y siempre usan diferentes herramientas también. Entonces, en mi último compromiso en el banco, usé Cypress para N10 testing, pero mis colegas que estaban escribiendo monitores estaban usando un tester PICA y Zebra. Y la realidad es que, si queremos unirnos y tratar de trabajar juntos para hacer sistemas más mantenibles, más confiables, y también compartir el camino cuando se trata de escribir estas automatizaciones, necesitamos usar un conjunto de herramientas común que todos podamos entender.

Y voy a pasar por un ejemplo, que puedes comprobar el código QR para echar un vistazo después si quieres, utilizando Playwrights, que es un marco de testing y automation de extremo a extremo mantenido por Microsoft, GitHub Actions para CI, y Elastic Synthetics para mostrar cómo una combinación de estas tecnologías puede permitirnos usar los mismos scripts como una prueba de extremo a extremo y desarrollo local en CI, y luego de nuevo como un monitor en producción. La forma en que estas herramientas interactúan es similar al flujo que tengo aquí. Así que sacando mi ratón, lo que verás es que tenemos un proyecto usando Elastic Synthetics y archivos de viaje TypeScript, que tienen interacciones de Playwright dentro de ellos. Y estos se sientan junto a esos monitores de latido vainilla, que se especifican en YAML. Y una de las grandes ventajas es que, esto efectivamente nos da monitores como código. Tenemos configuración en un repositorio, en lugar de tenerla configurada manualmente en una plataforma de UI y observability. Así que podemos ejecutar estos localmente contra una versión de la aplicación web para ver que todo está funcionando como se esperaba cuando construimos características. Y luego podemos subirlos al control de fuente, levantar ese PR, y luego ejecutarlos como pruebas de extremo a extremo para validar en la posible fusión que todo está funcionando como esperamos. Luego, cuando desplegamos nuestra aplicación al mismo tiempo, vamos a tomar esos mismos viajes, esos monitores, esas pruebas, y vamos a usar la autenticación de clave de API para empujarlos a la ubicación en la que vamos a ejecutarlos, y luego van a hacer ping contra la aplicación web de producción en su lugar, y luego procesar los resultados en la plataforma de observability para que podamos ver qué está pasando. Así que vamos a profundizar en un ejemplo, ¿deberíamos?. Así que esta es una prueba de Playwright vainilla que he escrito sólo para mostrar cómo funciona Playwright por sí solo antes de intentar integrar Elastic Synthetics juntos. Así que verás que estoy usando Playwright tests así que lo tengo instalado dentro de mi proyecto de aplicación web, y verás aquí que lo que estoy haciendo es que tengo dos pruebas, tengo una donde me estoy moviendo a la página de orden en esta pequeña aplicación de comercio electrónico que he construido, y tengo otra donde estoy añadiendo un artículo a la orden. Así que puedo usar el objeto de página dentro de Playwright para navegar, por ejemplo, yendo a la página de inicio, puedo usar varios localizadores para sacar los elementos particulares en la página que quiero. Así que por ejemplo aquí estoy sacando de forma asíncrona el botón de orden usando el atajo de get by test ID. Es importante notar que esto significa que he separado mi estilo y todos esos otros cambios de la lógica que saca mis elementos porque en esta ocasión en particular estoy usando el atributo data test ID que yo recomendaría que hagas también si aún no lo haces. Así que entonces puedo hacer clic en ese botón, puedo comprobar que he navegado a la página de orden como se esperaba y también puedo sacar todas las tarjetas de menú de artículo para ver que tengo algunas de esas. Y luego en mi añadir orden estoy yendo a la página de orden en su lugar. Estoy sacando todos los botones de añadir artículo de mis tarjetas de menú, comprobando que tengo algunos de ellos de nuevo y luego estoy obteniendo la etiqueta de conteo de carrito y luego estoy comprobando con los clics de los botones individuales de añadir artículo que este valor en particular está incrementando cada vez. Es una prueba relativamente sencilla. Así que

Puedo especificar opciones de Playwright como la capacidad de ignorar errores HTTPS. Puedo configurar los ajustes predeterminados para los monitores. Así que aquí estoy estableciendo que cada viaje del monitor se ejecutará cada diez minutos. De hecho, estoy usando la infraestructura elástica del Reino Unido. Pero si configuras el agente elástico en tu propia infraestructura, puedes ejecutarlo desde esa ubicación en su lugar. Solo sigue el asistente. Y luego especifico los ajustes del proyecto Elastic. Así ¿dónde está la URL para mi despliegue Elastic? ¿Hay una ID y en qué espacio de Kibana quiero que se sitúen? Lo cual podría ser útil si quizás tienes varios equipos cuidando diferentes conjuntos de aplicaciones puedes usar diferentes espacios de Kibana y derechos para segregarlos.

Avanzando, esta es la nueva prueba. Así que hay un par de cosas que han cambiado aquí. Lo primero que necesitamos señalar es que estamos utilizando Elastic Synthetics, pero todavía estamos usando Playwright porque también tenemos este objeto de página aquí. Es una dependencia explícita. Puedo anular los ajustes en un monitor individual. Así que si quieres eludir los valores predeterminados y tener un viaje particular que se ejecute con más frecuencia, quizás como una validation regular, entonces puedes hacerlo. Puedo hacer la configuración y desmontaje para configurar mis conjuntos de pruebas y desmontarlos usando antes y después, similar a las pruebas unitarias a las que estamos acostumbrados a usar. Y luego también puedo hacer los pasos. Pero lo que es diferente es que en lugar de tener pruebas individuales y más de un formato basado en unidades, realmente estamos inclinándonos más hacia los elementos de comportamiento del usuario. Así que tenemos un viaje, que envuelve toda la prueba individual, y tenemos pasos que luego capturarán una captura de pantalla de esa interacción individual. Así que si por ejemplo estás haciendo que resuelvas prácticas de desarrollo guiadas por el comportamiento para identificar comportamientos de usuario y afirmaciones, quizás estás usando técnicas como el mapeo de ejemplos en su lugar, cada uno de esos puntos individuales se mapeará a un paso individual en tu prueba, y luego simplemente estamos usando Playwright como normal para sacar elementos, usando localizador, probablemente debería estar usando GetByTestId en su lugar, y haciendo esos clics, entrada de texto, y otras acciones a las que estamos acostumbrados. Y luego si estamos haciendo prácticas de desarrollo guiadas por pruebas y dando vueltas a ese bucle, podemos ejecutar estas pruebas mientras estamos construyendo características y decir, hey, está funcionando como se esperaba, fantástico. Lo siguiente que necesitamos pensar es qué sucede en el punto CI cuando vamos a integrar no solo nuestros cambios de código, sino también esos cambios de prueba. Y hay dos tareas en las que necesitamos pensar. Así que aquí tengo un flujo de trabajo de GitHub actions y tengo dos trabajos dentro de él. Tengo un trabajo de prueba, que va a ejecutar ese conjunto de pruebas de extremo a extremo. Y luego tengo un trabajo de envío, que va a enviar los monitores a mi despliegue Elastic. Así que aquí verás que estoy usando el nodo entorno como desarrollo como una variable de entorno para asegurarme de que estoy usando la URL local pensando en nuestra configuración. Y lo que estoy haciendo es que estoy iniciando la aplicación. Estoy ejecutando el comando Elastic synthetics. Necesitas asegurarte de que tanto en el desarrollo local como aquí, realmente ejecutas el comando fuera de, dentro de la carpeta de viajes por eso establezco el directorio de trabajo aquí. Y luego hemos especificado el reportero JUnit, lo que significa que podré recibir los resultados de las pruebas publicadas dentro de cada ejecución de CI y ver si mis pruebas están teniendo éxito o fallando. Ahora, cuando se trata de empujar, necesitamos empujar con el entorno de nodo de producción, porque si no lo haces, lo que sucederá es que recogerá el valor predeterminado, pensando en ese archivo de configuración. Y lo que tendremos es una situación donde estás intentando hacer ping a los hosts locales, donde la aplicación no está funcionando y obtendrás monitores fallidos. Así que asegúrate de establecer el entorno correcto. También necesitas especificar tu clave API para authentication, asegurándote de almacenarla en una bóveda apropiada. No pongas la clave de texto plano en tu archivo de flujo de trabajo. Asegúrate de que depende de ese paso de prueba para que no empujemos monitores rotos inadvertidamente. Y luego desde dentro del directorio del proyecto, simplemente estamos ejecutando el comando de empuje,

Así que Playwright tiene capacidades de grabación y este es un grabador sintético de Elastic, que se sitúa en la parte superior. Y la idea es que puedes grabar a través de la interacción con tu aplicación en el navegador Chromium, todas las acciones que estás realizando. Luego puedes usar eso como base de tu prueba. Verás a través de la simulación que tengo aquí, que ha generado los pasos individuales. Soy capaz de añadir afirmaciones, que comprobarían cosas como la visibilidad. ¿Están habilitados o deshabilitados ciertos elementos? Todas esas cosas. Y si lo piensas, realmente me está permitiendo documentar lo que está sucediendo en la aplicación. Luego puedo ejecutar la prueba sólo para asegurarme de que los pasos que están fallando deberían estar fallando y los pasos que están pasando están pasando. Y luego puedo exportarlo como un archivo JavaScript para volver a ese repositorio de código de nuevo. Así que, podemos usar esto para recrear el problema que un usuario está viendo y empezar de nuevo y volver a pasar por el ciclo. Así que, hemos hablado mucho hoy. Hemos hablado de mi experiencia previa en DevOps y cómo, todavía me sorprende que realmente estemos luchando por unirnos. Hemos hablado de la idea de usar pruebas sintéticas y monitores de extremo a extremo utilizando los mismos artefactos. Porque ambos están automatizando la perspectiva del usuario. Y te he dado un ejemplo usando Playwright, Elastic Synthetics y GitHub Actions. Pero lo que quiero dejarles es que, independientemente de las herramientas que estén utilizando, lo más importante es hablar entre nosotros y alinearnos en un conjunto de herramientas que podamos utilizar. Así que, si tu plataforma de observability tiene una biblioteca de scripting diferente que te permite usar, intenta usar esas como tus pruebas de extremo a extremo para que puedas colaborar juntos. Porque al final eso es lo importante que hay que llevarse hoy. Y con eso, quiero decir muchas gracias, TestJS Summit. Ha sido un placer absoluto. Estaré por aquí si quieren hacer alguna pregunta. Compartiré las diapositivas. También compartiré el enlace al código si quieren ir y profundizar en él en GitHub actions y no han capturado el código QR, pero nos veremos la próxima vez. Adiós.