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

Rate this content
Bookmark

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.

19 min
11 Dec, 2023

AI Generated Video Summary

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

TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
TestJS Summit 2022TestJS Summit 2022
20 min
Testing Web Applications with Playwright
Testing is hard, testing takes time to learn and to write, and time is money. As developers we want to test. We know we should but we don't have time. So how can we get more developers to do testing? We can create better tools.Let me introduce you to Playwright - Reliable end-to-end cross browser testing for modern web apps, by Microsoft and fully open source. Playwright's codegen generates tests for you in JavaScript, TypeScript, Dot Net, Java or Python. Now you really have no excuses. It's time to play your tests wright.
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.
TestJS Summit 2022TestJS Summit 2022
21 min
Tiny Tests, Large Results
Yes, Big things do come in small packages. For example, isn’t a unit test’s speed, feedback, and reliability fantastic? Did you know we can also have fast, focused, and reliable feedback from our functional e2e tests? Atomic e2e tests are those that are targeted and focused. They’re tiny in size but large in their impact. This tutorial will teach you how to create atomic e2e tests with several code examples. First, we will use Cypress.io to authenticate by setting a cookie. Instead of using a UI. Second, we will use Cypress.io to set a JSON Web Token for authentication. Join me, and let’s write tiny tests for large results.
TestJS Summit 2022TestJS Summit 2022
17 min
Testing Mail Service With Playwright
We send emails to our users - account verification and newsletters. We allow the user to contact us by sending an email via inbuild form. Do we? Does the user receive an account verification email or exactly what notification they signed up for? We can cover this functionality as part of E2E tests: get an email and open it to check what is in it. We will need Playwright and a fake SMTP server to capture emails sent by the app.

Workshops on related topic

React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
89 min
Building out a meaningful test suite that's not all E2E
Workshop
We're all taught to follow the Testing Pyramid but the reality is that we build out the Testing Christmas Tree. In this workshop, David will talk you through how to break down projects and put the tests where they need to be. By the end of the workshop you will be able to update your projects so that anyone and everyone can start contributing and truly living up to "Quality is everyone job".
He will walk you through:- Component Testing- API Testing- Visual Regression Testing- A11Y testing
He will also talk you through how to get these all setup in your CI/CD pipeline so that you can get shorter and faster feedback loops.
DevOps.js Conf 2022DevOps.js Conf 2022
155 min
Powering your CI/CD with GitHub Actions
Workshop
You will get knowledge about GitHub Actions concepts, like:- The concept of repository secrets.- How to group steps in jobs with a given purpose.- Jobs dependencies and order of execution: running jobs in sequence and in parallel, and the concept of matrix.- How to split logic of Git events into different workflow files (on branch push, on master/main push, on tag, on deploy).- To respect the concept of DRY (Don't Repeat Yourself), we will also explore the use of common actions, both within the same repo and from an external repo.
JSNation 2022JSNation 2022
101 min
JS Security Testing in GitHub Actions
WorkshopFree
This workshop will focus on automating software composition analysis, static application security testing and dynamic application security testing using GitHub Actions. After a brief introduction covering the different types of application security and the importance of finding security vulnerabilities before they hit production, we'll dive into a hands-on session where users will add three different security testing tool to their build pipelines.
TestJS Summit 2022TestJS Summit 2022
87 min
Automate WebApp Security Testing using GitHub Actions (from StackHawk team)
WorkshopFree
Software development has changed - Frequent deployments, APIs, GraphQL, Cloud Architecture and CI/CD Automation are the norm. So why is security testing the same way it was a decade ago?
Leading teams are realizing that periodical penetration testing and security audits is not enough when code is being shipped daily. Instead, these teams are using developer-centric tools to run automated security testing in a CI/CD pipeline. Join Zachary Conger as he walks through how to automate application JS security testing using GitHub actions.