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

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

A pesar de la emergencia de DevOp para unir desarrollo, soporte y facciones SRE utilizando procesos comunes, todavía enfrentamos desafíos culturales y de herramientas que crean los silos de Dev y Ops. Específicamente, a menudo usamos diferentes herramientas para lograr pruebas similares: un caso en punto es validar la experiencia del usuario en producción utilizando Monitoreo Sintético y en desarrollo utilizando pruebas e2e. Al unir fuerzas en torno a herramientas comunes, podemos usar la misma herramienta tanto para el monitoreo de producción como para las pruebas dentro de CI. En esta charla, discutiré cómo el Monitoreo Sintético y las Pruebas e2e son dos caras de la misma moneda. Además, mostraré cómo se puede lograr el monitoreo de producción y las pruebas de desarrollo utilizando Playwright, GitHub Actions y Elastic Synthetics.

This talk has been presented at TestJS Summit 2023, check out the latest edition of this JavaScript Conference.

FAQ

Carly Richmond es una desarrolladora senior en Elastic y tiene una amplia experiencia como ingeniera de software, incluyendo responsabilidades en gestión de producción y resolución de problemas de usuarios en sistemas regulatorios.

Carly Richmond habló sobre las pruebas de extremo a extremo y el monitoreo sintético, destacando cómo estos elementos pueden considerarse dos caras de la misma moneda y demostrando cómo pueden integrarse con GitHub Actions y Elastic Synthetics.

El desplazamiento a la izquierda es una práctica en desarrollo de software que implica detectar defectos más temprano en el ciclo de desarrollo, con el objetivo de mejorar la calidad y reducir los tiempos de respuesta en la solución de problemas.

Según Carly Richmond, tanto las pruebas de extremo a extremo como el monitoreo sintético automatizan la perspectiva del usuario y a menudo utilizan scripts similares, lo que sugiere que pueden ser integrados y gestionados de manera más eficiente con herramientas comunes.

Integrar Playwright, GitHub Actions y Elastic Synthetics permite usar los mismos scripts para pruebas de extremo a extremo y monitoreo en producción, facilitando la gestión y mejora de la calidad y confiabilidad de las aplicaciones.

Los equipos a menudo enfrentan falta de empatía entre desarrolladores y operadores, prioridades desalineadas y herramientas dispares, lo que dificulta la colaboración y la eficiencia entre los distintos grupos involucrados.

La colaboración entre diferentes disciplinas, como desarrolladores, testers, SREs y gestores de producto, es crucial para crear sistemas más mantenibles y confiables, optimizando el uso de recursos y mejorando la experiencia del usuario final.

Carly Richmond
Carly Richmond
19 min
11 Dec, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Carly Richmond discute la importancia de cambiar a la izquierda en las pruebas y el monitoreo. Ella enfatiza la necesidad de empatía y un conjunto de herramientas común en el proceso de desarrollo de software. La charla explora el uso de pruebas de extremo a extremo y monitoreo sintético, mostrando un ejemplo con Playwrights, GitHub Actions y Elastic Synthetics. También cubre la configuración, configuración e integración de pruebas en el flujo de trabajo de CI. La charla concluye con los beneficios de monitorear el estado de la aplicación y la prueba, y la importancia de la colaboración en la recreación de problemas.

1. Introducción a las Pruebas y Monitoreo

Short description:

Hola, TestJS Summit. Mi nombre es Carly Richmond. Soy una desarrolladora senior en Elastic. Hoy, hablaré sobre las pruebas de extremo a extremo y el monitoreo sintético, mostrando un ejemplo de cómo combinar un marco de pruebas de extremo a extremo con acciones de GitHub para CI y monitoreo utilizando Elastic Synthetics.

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.

2. Entendiendo los Desafíos

Short description:

Pero antes de todo eso, necesitamos hablar sobre la noción de desplazamiento a la izquierda porque eso es imperativo para entender este argumento. Mi experiencia con eso fue realmente mi idea inicial sobre por qué DevOps tiene sentido, porque estábamos trabajando juntos. 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. La otra cosa es la falta de prioridad común. 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.

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

3. Pruebas de extremo a extremo y monitoreo sintético

Short description:

Esta sección discute el uso de pruebas de extremo a extremo y monitoreo sintético. Destaca la necesidad de un conjunto de herramientas común e introduce un ejemplo utilizando Playwrights, GitHub Actions y Elastic Synthetics. El ejemplo demuestra cómo estas tecnologías pueden ser utilizadas para el desarrollo local, CI y monitoreo de producción. La sección concluye con una prueba de Playwright vainilla que prepara el escenario para la integración de Elastic Synthetics.

y valida la user experience. Por lo tanto, realiza acciones como clics y entrada de texto que un usuario haría y te permite validar que la aplicación en su conjunto se comporta como se esperaba. Y en mi experiencia escribiendo estas pruebas como desarrollador, terminamos usando Cypress cuando usábamos Protractor para Angular, que afortunadamente ya no existe.

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

4. Configuración de NetWizard y Synthetics

Short description:

El uso de una instalación global te permite utilizar NetWizard para generar una estructura con tres elementos: la carpeta de journeys para los monitores de prueba de extremo a extremo, los monitores ligeros en sintaxis YAML y la configuración de synthetics para configurar los monitores en Elastic Synthetic.

si ahora queremos hacer uso de Elastic Synthetics en la parte superior, necesitamos instalarlo. Así que usar una instalación global te permitirá usar el NetWizard, que tengo aquí, especificando el proyecto que quiero crear y en ese caso, generará una estructura un poco como esta. Así que hay tres elementos aquí. Tenemos la carpeta de journeys, que es donde están estos monitores de prueba de extremo a extremo, y se generan en TypeScript. Pero por supuesto, podrías usar JavaScript si quisieras. También podemos ver los monitores ligeros. Así que estos están en sintaxis YAML. No los estamos cubriendo hoy. Pero ve a echarles un vistazo si quieres ver cómo son. Pero harán ping a cualquier punto que especifiques en una frecuencia fija. Y luego tenemos synthetics config. Esta es la configuración para cuando empujamos los monitores a Elastic Synthetic para que sepa qué hacer. Así que vamos a profundizar en esta configuración, ¿deberíamos? Así que ves aquí que tengo una configuración

5. Configuración y Ajustes

Short description:

Puedo especificar opciones de Playwright como la capacidad de ignorar errores HTTPS. Puedo configurar los ajustes predeterminados para los monitores. 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.

objeto. Y estoy especificando los parámetros aquí para localhost por defecto. Pero si me desplazo todo el camino hasta el fondo desde la línea 28, lo que verás es que si el ambiente es producción, estoy cambiando el parámetro para apuntar a mi aplicación de producción. Y esto significa que recogerá la URL correcta dependiendo del entorno de nodo que se pasa.

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.

6. Configuración de Pruebas e Integración CI

Short description:

En esta sección, discutimos la nueva configuración de pruebas utilizando Elastic Synthetics y Playwright. Exploramos el concepto de viajes y pasos, que capturan el comportamiento e interacciones del usuario. También cubrimos la integración de cambios de prueba en el flujo de trabajo CI, incluyendo la ejecución del conjunto de pruebas de extremo a extremo y el envío de monitores a la implementación de Elastic. Es importante establecer el entorno correcto y especificar la clave API para la autenticación al enviar monitores.

¿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,

7. Monitoreo de la Aplicación y el Estado de las Pruebas

Short description:

Podemos monitorear el estado actual de nuestra aplicación y pruebas. El verde indica éxito, y podemos rastrear la duración de las pruebas a lo largo del tiempo. Podemos configurar alertas para fallos de pruebas y utilizar asistencia de IA para un análisis más profundo. Podemos ver fallos, información de rastreo y capturas de pantalla de cada página. Además, podemos monitorear la duración de cada paso para identificar cualquier degradación.

que se configura con ese asistente de inicio. Y cuando hacemos eso, terminamos con esto. Así que hemos enviado nuestra aplicación en un paso separado. Ahora hemos enviado nuestros monitores. Puedes ver cada una de las tarjetas mostrando el estado actual. Así que el verde significa que estamos bien. También podemos ver cuánto tiempo están tardando estas pruebas en ejecutarse, lo cual es importante cuando consideramos cosas como las pruebas de extremo a extremo que a menudo se degradan con el tiempo. Pueden tardar cada vez más en ejecutarse. Y queremos intentar detectar eso para ver si hay quizás un problema que necesitamos plantear para solucionar. Y podemos ver la duración corriendo a lo largo del tiempo. También podemos empezar a hacer cosas inteligentes. Así que tal vez podemos ejecutar y disparar alertas cuando una prueba en particular falla. Quizás podemos usar IA para obtener información sobre lo que está sucediendo dentro de nuestros data y obtener un análisis más profundo. Pero también somos capaces de ver los fallos. Somos capaces de ver exactamente cuál es el rastro. Somos capaces de ver las capturas de pantalla de cada página para ver cómo se veía. Y como puedes ver aquí en la esquina, puedo ver la duración de cada paso. Así que puedo ver si un paso individual está empezando a

8. Recreación de Problemas y Colaboración

Short description:

En un mundo ideal, los equipos multidisciplinares trabajan juntos para crear trayectorias similares para la recreación de problemas. Las capacidades de grabación de Playwright permiten a los usuarios documentar y simular interacciones, añadir afirmaciones y exportar pruebas como archivos JavaScript. Independientemente de las herramientas utilizadas, la clave es comunicarse y alinearse en un conjunto de herramientas común para la colaboración. ¡Gracias, TestJS Summit!

se degradan también. Así que esto es genial, pero todos sabemos que no podemos capturar todo y a veces un usuario va a pedir ayuda. Y cuando eso sucede, lo que necesitamos ser capaces de hacer es asegurarnos de que podemos crear trayectorias similares para retroalimentar el ciclo de nuevo. Pero si en un mundo ideal, de hecho estamos trabajando en equipos multidisciplinares con ese propietario del producto, con probadores, con desarrolladores, con diseñadores, con SREs. No todo el mundo va a tener experiencia en Playwright y a veces poder grabar lo que el usuario está haciendo para recrear un problema puede ser útil.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Pruebas de Aplicaciones Web con Playwright
TestJS Summit 2022TestJS Summit 2022
20 min
Pruebas de Aplicaciones Web con Playwright
Top Content
Testing web applications with Playwright, a reliable end-to-end testing tool. Playwright offers fast execution, powerful tooling, and support for multiple languages. It provides precise selectors, web-first assertions, and code generation for easy testing. Playwright also offers features like live debugging, tracing, and running tests on CI. The future of Playwright aims to make testing easy and fun, with a focus on creating frustration-free web experiences.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Automatizando Todo el Código y las Pruebas con GitHub Actions
React Advanced 2021React Advanced 2021
19 min
Automatizando Todo el Código y las Pruebas con GitHub Actions
Top Content
We will learn how to automate code and testing with GitHub Actions, including linting, formatting, testing, and deployments. Automating deployments with scripts and Git hooks can help avoid mistakes. Popular CI-CD frameworks like Jenkins offer powerful orchestration but can be challenging to work with. GitHub Actions are flexible and approachable, allowing for environment setup, testing, deployment, and custom actions. A custom AppleTools Eyes GitHub action simplifies visual testing. Other examples include automating content reminders for sharing old content and tutorials.
Todos pueden escribir pruebas fácilmente
TestJS Summit 2023TestJS Summit 2023
21 min
Todos pueden escribir pruebas fácilmente
Playwright is a reliable end-to-end testing tool for modern web apps that provides one API, full isolation, fast execution, and supports multiple languages. It offers features like auto-weighting, retrying assertions, seamless testing of iframes and shadow DOM, test isolation, parallelism, and scalability. Playwright provides tools like VS Code extension, UiMode, and Trace Viewer for writing, debugging, and running tests. Effective tests prioritize user-facing attributes, use playwright locators and assertions, and avoid testing third-party dependencies. Playwright simplifies testing by generating tests, providing code generation and UI mode, and allows for easy running and debugging of tests. It helps in fixing failed tests and analyzing DOM changes, fixing locator mismatches, and scaling tests. Playwright is open source, free, and continuously growing.
Pruebas pequeñas, grandes resultados
TestJS Summit 2022TestJS Summit 2022
21 min
Pruebas pequeñas, grandes resultados
Automated atomic tests are a great way to improve UI tests by making them less brittle and faster. The tests focus on testing a single feature or component and have minimal UI interactions. The Talk explores examples of automated atomic tests and their implementation on web applications. It also discusses the analysis of atomic tests, login tests, and working with JSON Web Tokens for authentication and authorization. The Talk concludes by highlighting the use of UI and web requests in automated atomic testing.
Quizá No Necesitemos Pruebas de Componentes
Vue.js Live 2024Vue.js Live 2024
26 min
Quizá No Necesitemos Pruebas de Componentes
Component testing is a gray area between integration and unit testing. The demo app focuses on the cart component and writing test cases for Playwright component test and VTest. The first cart test encounters a bug with the invisible method in View Test.

Workshops on related topic

Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.
Construyendo una suite de pruebas significativa que no sea todo E2E
TestJS Summit 2023TestJS Summit 2023
89 min
Construyendo una suite de pruebas significativa que no sea todo E2E
Workshop
David Burns
David Burns
Todos somos enseñados a seguir la Pirámide de Pruebas pero la realidad es que construimos el Árbol de Pruebas de Navidad. En esta masterclass, David te explicará cómo desglosar proyectos y poner las pruebas donde necesitan estar. Al final de la masterclass, podrás actualizar tus proyectos para que cualquiera y todos puedan empezar a contribuir y realmente vivir según "La calidad es el trabajo de todos".
Te guiará a través de:- Pruebas de Componentes- Pruebas de API- Pruebas de Regresión Visual- Pruebas A11Y
También te explicará cómo configurar todo esto en tu pipeline de CI/CD para que puedas obtener ciclos de feedback más cortos y rápidos.
Automatizar Pruebas de Seguridad de Aplicaciones Web usando GitHub Actions (del equipo de StackHawk)
TestJS Summit 2022TestJS Summit 2022
87 min
Automatizar Pruebas de Seguridad de Aplicaciones Web usando GitHub Actions (del equipo de StackHawk)
Workshop
Zachary Conger
Zachary Conger
El desarrollo de software ha cambiado: Despliegues frecuentes, APIs, GraphQL, Arquitectura en la Nube y Automatización CI/CD son la norma. Entonces, ¿por qué las pruebas de seguridad siguen siendo iguales que hace una década?
Los equipos líderes se están dando cuenta de que las pruebas de penetración periódicas y las auditorías de seguridad no son suficientes cuando el código se envía a diario. En su lugar, estos equipos están utilizando herramientas centradas en los desarrolladores para ejecutar pruebas de seguridad automatizadas en un pipeline de CI/CD. Únete a Zachary Conger mientras te guía en cómo automatizar las pruebas de seguridad de aplicaciones JS utilizando GitHub Actions.
Potenciando tu CI/CD con GitHub Actions
DevOps.js Conf 2022DevOps.js Conf 2022
155 min
Potenciando tu CI/CD con GitHub Actions
Workshop
David Rubio Vidal
David Rubio Vidal
Obtendrás conocimiento sobre los conceptos de GitHub Actions, como:- El concepto de secretos de repositorio.- Cómo agrupar pasos en trabajos con un propósito determinado.- Dependencias y orden de ejecución de trabajos: ejecutar trabajos en secuencia y en paralelo, y el concepto de matriz.- Cómo dividir la lógica de los eventos de Git en diferentes archivos de flujo de trabajo (en empuje de rama, en empuje a master/principal, en etiqueta, en implementación).- Para respetar el concepto de DRY (No te repitas), también exploraremos el uso de acciones comunes, tanto dentro del mismo repositorio como desde un repositorio externo.
Pruebas de seguridad de JS en GitHub Actions
JSNation 2022JSNation 2022
101 min
Pruebas de seguridad de JS en GitHub Actions
Workshop
Zachary Conger
Zachary Conger
Este masterclass se centrará en automatizar el análisis de composición de software, las pruebas de seguridad de aplicaciones estáticas y las pruebas de seguridad de aplicaciones dinámicas utilizando GitHub Actions. Después de una breve introducción que cubre los diferentes tipos de seguridad de aplicaciones y la importancia de encontrar vulnerabilidades de seguridad antes de que lleguen a producción, nos sumergiremos en una sesión práctica donde los usuarios agregarán tres herramientas de pruebas de seguridad diferentes a sus pipelines de construcción.