¿Playwright puede hacer esto?

Rate this content
Bookmark

Garantizar que tu aplicación no se rompa mientras envías constantemente nuevas características es difícil. Obviamente, con una aplicación o sitio en constante crecimiento, no puedes probar todo manualmente todo el tiempo.

La automatización de pruebas y el monitoreo son cruciales para evitar enviar aplicaciones y sitios rotos. Pero, ¿qué funcionalidad debes probar? ¿Cuándo debes ejecutar tus pruebas? ¿Y no son las suites de pruebas complejas muy lentas?

En esta sesión, pondremos manos a la obra con Playwright, el marco de pruebas de extremo a extremo, y aprenderemos cómo automatizar navegadores sin cabeza para asegurarnos de enviar nuevas características con confianza.

23 min
03 Nov, 2022

Video Summary and Transcription

Playwright es una poderosa herramienta para pruebas de extremo a extremo, que ofrece soporte para todos los principales navegadores y plataformas. Proporciona características como paralelización, espera incorporada y aserciones. Playwright permite ejecutar pruebas en múltiples navegadores con un solo comando y tiene funcionalidad para generar pruebas y realizar pruebas de regresión visual. También permite la manipulación de la capa de red y la carga de los componentes internos de las páginas web. Las mejores prácticas incluyen el uso de scripts cortos e idempotentes, dividir los flujos de cuenta de usuario en pruebas separadas y limpiar después de cada caso de prueba.

Available in English

1. Introducción a Playwright y Pruebas de Extremo a Extremo

Short description:

Hola, TestJS Summit. Es hora de otra sesión de Playwright. Playwright puede hacer esto. Soy Stefan de Berlín, Alemania, aunque estoy en Grecia en este momento. Me dedico al desarrollo front-end, desarrollo de JavaScript, desde hace un tiempo. Y trabajo para una empresa llamada checkly, donde hacemos monitoreo de API y pruebas de extremo a extremo en la nube.

Hola, TestJS Summit. Es hora de otra sesión de Playwright. Playwright puede hacer esto.

Y antes de comenzar, permítanme presentarme rápidamente. Soy Stefan de Berlín, Alemania, aunque estoy en Grecia en este momento. Me dedico al desarrollo front-end, desarrollo de JavaScript, desde hace un tiempo. Y trabajo para una empresa llamada checkly, donde hacemos monitoreo de API y pruebas de extremo a extremo en la nube. Así que si quieres controlar y ejecutar Playwright según un horario, en la nube, para asegurarte de que todos tus productos estén funcionando en todo momento, puedes echar un vistazo a checkly. Y estoy seguro de que te parecerá interesante.

Y déjame decirte que comencé a hacer pruebas hace más de 10 años, y estas fueron las tecnologías, las elecciones tecnológicas con las que comencé a experimentar. Mis primeras pruebas de interfaz de usuario y extremo a extremo las escribí en Selenium. Y luego, en algún momento, apareció Phantom JS, este nuevo y elegante marco o biblioteca impulsada por JavaScript para controlar WebKit sin cabeza. Y luego, más tarde, apareció Casper JS. Así que teníamos una cosa con fantasmas en ese momento, que era un marco de pruebas sobre Phantom JS. Y déjame decirte que desde el principio, desde las primeras posibilidades de controlar un navegador para probar que las cosas que realmente puse en línea funcionan, fui un gran fanático de este enfoque porque la idea de las pruebas de extremo a extremo siempre me pareció atractiva. Porque puedes probar tus sitios web y aplicaciones realmente de extremo a extremo, comenzando en el navegador y tal vez terminando en la base de datos y las pruebas y cubriendo todas las cosas intermedias. Ya sean APIs, servidores web o cualquier cosa que estés construyendo.

2. Desafíos con las Pruebas de Extremo a Extremo

Short description:

Cuando escribí mi primera prueba de extremo a extremo, fue una experiencia terrible. El conjunto de pruebas era lento, inestable y no disfrutábamos escribir pruebas. Esperar las luces verdes y lidiar con falsos positivos lo empeoraba aún más. Invertimos mucho tiempo pero nos dimos cuenta de que no valía la pena. Ejecutar pruebas a pedido no es suficiente. Queremos que las pruebas se ejecuten todo el tiempo, en cada confirmación, en cada implementación.

Cuando escribí mi primera prueba de extremo a extremo, sin embargo, fue una experiencia terrible. Pasé, por ejemplo, sprint tras sprint con mis colegas y mi equipo para lograr una buena cobertura de pruebas de extremo a extremo, solo para crear un conjunto de pruebas que era lento, no disfrutábamos escribir pruebas y era inestable. Fue el peor escenario posible terminar con un conjunto de pruebas lento, tener que esperar 30, 40, 50 minutos para obtener una luz verde para tal vez implementar una corrección de errores tipográficos, pero luego también obtener resultados falsos positivos para que vuelvas a ejecutar tus pruebas de extremo a extremo para asegurarte de que, bueno, tal vez las pruebas no estaban correctas y luego se ejecutan más tarde, probablemente hayas estado en esa situación. Este es el peor escenario posible cuando no puedes confiar en tu conjunto de pruebas y también es lento. Así que estuvimos en esa situación, invertimos mucho tiempo y en algún momento decidimos que no valía la pena, y optamos por ejecutar las pruebas a pedido, ¿verdad? Y tal vez tú también hayas estado en esa situación, pero este es el momento en el que prácticamente renuncias a las pruebas de extremo a extremo, porque lo que quieres es que tus pruebas se ejecuten todo el tiempo, en cada confirmación, en cada implementación, quieres que estén en tu radar en todo momento. Y cuando las ejecutas a pedido, bueno, eso probablemente no es lo suficientemente frecuente, por lo que terminarás con un conjunto de pruebas desactualizado muy rápidamente, porque lo olvidaste, y esto está anulando todo el esfuerzo que has realizado. Y esto es exactamente lo que me sucedió.

3. Introducción a las Pruebas de Playwright

Short description:

Puppeteer y Cypress fueron los primeros pasos en la automatización del navegador, pero Playwright es una solución muy decente para las pruebas de extremo a extremo. Es inclusivo, compatible con todos los principales navegadores y múltiples plataformas. Playwright Test es un marco de pruebas completo con características convenientes como la paralelización, la espera incorporada y las afirmaciones. Echemos un vistazo a Playwright y ejecutemos algunas pruebas en VS Code.

Afortunadamente, las cosas mejoraron mucho. Puppeteer fue el primer paso para la automatización oficial del navegador, respaldado por Google para Chrome, y luego Cypress apareció hace unos años con una sólida experiencia de desarrollo, y tal vez lo hayas adivinado, desde hace mucho tiempo estoy probando Playwright, y creo que es una solución muy, muy decente para las pruebas de extremo a extremo.

Entonces, permíteme mostrarte de qué se trata Playwright. En caso de que no hayas visto la charla de Debbie, primero, Debbie del equipo de Playwright habló sobre Playwright hace unos momentos. Playwright es una solución de pruebas muy inclusiva. Incluye todos los principales navegadores, como Chromium, WebKit y Gecko Firefox. Se ejecuta en Mac, Windows y Linux, y puedes escribir pruebas principalmente en JavaScript y TypeScript. Si .NET, Python y Java son lo tuyo, también puedes hacerlo. Desde el punto de vista de la inclusividad, Playwright es de primera categoría. Además, si VS Code es tu editor de elección, la extensión de Playwright para VS Code funciona muy bien para crear pruebas de Playwright, depurarlas, generarlas y ejecutarlas. Puedes hacer toda esta funcionalidad de extremo a extremo y funcionalidad de pruebas directamente desde tu editor. Si esto es lo que te gusta, puedes usar VS Code, así que eso es muy bueno.

Me llevó un tiempo darme cuenta de que Playwright es más que un controlador de navegador. Playwright Test, en estos días, es un marco de pruebas completo que viene con la funcionalidad habitual de describir, ganchos antes de cada uno, después de cada uno, fixtures, configuración de pruebas. Todas estas cosas buenas están incluidas en Playwright en sí. Entonces, cuando realmente quieres ir a fondo en las pruebas de extremo a extremo, Playwright es una solución valiosa aquí. Es fácil de paralelizar. Así que recuerda mi historia de ejecutar pruebas y esperar 30, 40 minutos. Con Playwright, puedes paralelizar todas tus pruebas con un solo argumento de la CLI o ponerlo en tu configuración para acelerar lo que sucede y lo que está sucediendo. Y, hasta ahora, mi favorito es que Playwright está diseñado para una ejecución rápida con características como la espera automática y las afirmaciones web-first, porque las pruebas de interfaz de usuario suelen ser así, bueno, esperas algo, haces algo con eso y luego esperas a que aparezca lo siguiente para hacer algo con eso. Y generalmente esto significa que tuve que poner retrasos arbitrarios aquí y allá o esperar manualmente a que aparezcan o desaparezcan elementos. Playwright tiene todo esto incorporado y esto me emociona mucho. Debbie lo mencionó brevemente, pero quiero mostrarte cómo funciona esto en esta sesión también. Entonces, ¿echamos un vistazo? Echemos un vistazo a Playwright y ejecutemos algunas pruebas. Entonces, vamos a VS Code y lo que ves aquí a la derecha es mi terminal. Y a la izquierda, tenemos el archivo test.js spec.js, que es un archivo de prueba estándar. Y lo que vamos a probar es este hermoso sitio web aquí, que está en localhost 8080. Y es el sitio del evento test.js summit y es prácticamente el mismo sitio, pero ahora incluye este enorme botón de celebración, porque creo que más sitios web deberían tener confeti. Aparte de eso, cuando miramos la configuración del proyecto aquí, encontrarás una configuración de Playwright estándar y además, hay una carpeta de pruebas que incluye test.js spec.js y este pequeño facebomb.js son solo mis notas aquí en caso de que te lo estés preguntando. No estamos usando la extensión de VSCode aquí, así que para ejecutar este proyecto y ejecutar las pruebas que se incluyen en él, lo que puedes hacer es npx playwright test y ya ves que hay 28 pruebas descubiertas usando cinco trabajadores y ya vemos que se está realizando la paralelización aquí, pero vamos a ver qué sucede aquí ahora mismo. Vemos que hay siete pruebas aprobadas y 21 omitidas y cuando miramos el archivo de prueba, vemos que hay una prueba oficial o habilitada y las otras tres están omitidas, pero ¿por qué todo está multiplicado por siete? Entonces, cuando vamos a la configuración de Playwright, verás que en este momento hay varios y múltiples navegadores configurados para ejecutarse cuando ejecutamos las pruebas de Playwright.

4. Ejecución de Múltiples Navegadores

Short description:

Puedes ejecutar múltiples navegadores con un solo comando. Es genial ver todas las ventanas emergiendo. Podemos desactivar la mayoría de los navegadores para ahorrar tiempo.

Entonces tenemos Chromium, Firefox, WebCorp, Mobile Chrome, Mobile Safari, Microsoft Edge, Google Chrome. Esto muestra que puedes ejecutar todos estos navegadores con un solo comando y para demostrarte que esto realmente funciona, lo que podemos hacer es pasar el argumento 'headed'. Y ahora solo vemos un montón de ventanas emergiendo, emulando un navegador específico y testing que todo está yendo bien y funcionando correctamente. Y creo que esto ya es bastante, bastante genial ver todas estas ventanas emergiendo. Pero por ahora, creo que podemos desactivar la mayoría de los navegadores para no tener que esperar por ellos en el futuro.

5. Generación de Pruebas con Playwright

Short description:

Debbie mostró cómo generar pruebas utilizando la extensión de Vscode o la línea de comandos. Al ejecutar npx playwright codegen con una URL, se abre el Inspector de Playwright y registra todas las acciones. Esto proporciona un inicio rápido para escribir pruebas. Vamos a explorar las pruebas más a fondo.

Entonces, ¿qué más tenemos? Debbie mostró en su charla que puedes usar la extensión de Vscode para generar pruebas. También puedes hacer lo mismo desde la línea de comandos. Así que lo que hice aquí fue ejecutar npx playwright codegen con una URL. Y ahora lo que sucedió es que se abrió el Inspector de Playwright. Y ahora todo lo que hagamos en esta pequeña ventana aquí, vamos a hacer clic aquí, vamos a hacer esto y hacer esto. Verás que está registrando todas las acciones. Ahora puedo ir aquí, copiar y pegar esto, agregar algunas afirmaciones y obtener un inicio rápido utilizando codegen si quieres hacer esto. Pero vamos a echar un vistazo a las pruebas y empezar a jugar con algunas pruebas.

6. Prueba de Título de Página y Regresión Visual

Short description:

Entonces, lo que tenemos aquí es una prueba que verifica que la página actual tenga el título correcto. Podemos ejecutar esta prueba y fallará porque el título es incorrecto. Playwright también viene con un modo de depuración para facilitar la solución de problemas. Playwright tiene funcionalidad de captura de pantalla para capturar el estado actual del sitio web. También admite pruebas de regresión visual con una línea de código.

Entonces, lo que tenemos aquí es, en primer lugar, una prueba que verifica que la página actual tenga el título correcto. Y puedes ver que hay un bloque de antes de cada uno que ya va a localhost. Verifica el título, localiza el elemento h1 y luego realiza una afirmación de cadena de que el titular tiene la prueba correcta. Entonces, ¿por qué no romper esta afirmación aquí? Veamos qué sucede.

Podemos ejecutar esta prueba y ahora fallará porque mientras se ejecutan las pruebas, no tendrá tres S aquí y volveremos a intentarlo varias veces aquí. Pero lo que vemos ahora es que tenemos una prueba fallida. Entonces, ¿cómo podríamos debug esto? Incluso en la línea de comandos, Playwright también viene con un modo de debug. Entonces, lo que ves aquí es esta sesión del navegador y nuevamente el inspector de Playwright que nos permite seguir todas las instrucciones de las pruebas reales aquí y debug y ver qué está sucediendo. Y creo que eso es solo una adición práctica si no quieres usar la extensión de VS code.

Avanzando, lo que quiero mostrarte es que, en primer lugar, Playwright tiene la funcionalidad normal o común de captura de pantalla incorporada. Entonces, cuando ejecutas un navegador headless, a menudo te preguntas, ¡Oye, cuál es el estado actual del sitio web? Entonces, puedes hacer lo mismo. Puedes ejecutar una captura de pantalla de la página en blanco para tomar una captura de pantalla de la página actual y ahora acabamos de generar un nuevo PNG aquí, que incluye el estado actual de este sitio web. Lo que es genial, sin embargo, es que Playwright también tiene la funcionalidad de captura de pantalla, regresión visual testing incorporada. Entonces, lo que también podemos hacer es lo que tenemos aquí es un localizador para un titular. Entonces, hagamos wait, expect. Ahora podemos tomar el titular y podemos decir que tenga una captura de pantalla y le damos la captura de pantalla titular PNG. Y cuando, lo que sucede aquí es que estamos vinculando una afirmación a un localizador. Vamos a capturar una captura de pantalla de este elemento en particular que coincide con este localizador. Y luego, para las ejecuciones siguientes, estamos comparando las capturas de pantalla. Entonces, esto es una regresión visual testing con una línea de código. Entonces, cuando ahora ejecuto esto inicialmente, fallará porque no hay una instantánea, una instantánea generada aún. Pero cuando vemos el resultado de este primer fallo, ahora hay un nuevo directorio que es testjess.spec.js.snapshots. Y ahora ves aquí, esta nueva instantánea que acabamos de crear. En el futuro, cuando volvamos a ejecutar la prueba, siempre pasará porque Playwright tomará una captura de pantalla. Veremos si coincide con lo que esperamos y continuará. Entonces, si ahora ajustamos y jugamos un poco con esta captura de pantalla aquí, que es la línea base para la comparación, y ejecutamos la prueba nuevamente, fallaremos porque acabamos de afectar la comparación de la regresión visual. Y cuando miramos en la carpeta de resultados de la prueba aquí, ahora ves que esta fue la imagen que esperábamos con muchas líneas rayadas en ella. Esta fue la imagen que se generó en esta ejecución de prueba actual. Y aquí tenemos la regresión visual que nos muestra, ¡Oye, algo cambió en tu componente que tienes en tus pruebas de Playwright! Y todavía me sorprende que con una sola línea de instrucciones de prueba, puedas tener una regresión visual basada en componentes testing.

7. Sobrescribir y probar la funcionalidad de Confetti

Short description:

Para sobrescribir lo que acabamos de tener, podemos actualizar las instantáneas. Probemos la funcionalidad de Confetti. Playwright tiene una funcionalidad de espera incorporada. Podemos aprovechar las afirmaciones web-first para verificar la presencia de elementos de lienzo. Esto agiliza el código de prueba de extremo a extremo. También podemos manipular la capa de red y las partes internas de carga de las páginas web.

Para sobrescribir lo que acabamos de tener, lo que podemos hacer es actualizar las instantáneas. Y ahora volvemos a la captura de pantalla correcta, que tendremos aquí sin líneas de rayado para que todas nuestras pruebas pasen. Así que esto es bueno.

Pero sigamos adelante y probemos que esta funcionalidad de Confetti tan importante esté funcionando. Entonces, lo que ves aquí es que ya tengo el botón, que es el botón de Confetti de fiesta. Y estoy localizando todos los elementos de lienzo en esta página. Entonces, cuando miramos esto y recargamos la página, verás que en realidad hay un poco de retraso para que aparezca el botón. Entonces, lo que sucede es que, en primer lugar, tenemos que esperar a que aparezca este botón, luego tenemos que hacer clic en él, luego tenemos que esperar a que el lienzo renderice todo el Confetti. Y después de que el Confetti haya terminado, también se eliminará automáticamente el lienzo. Y esto incluye mucha espera.

Si quisiéramos probar esto, pero lo bueno de esto es que Playwright tiene toda la funcionalidad de espera incorporada. Entonces, lo que podemos hacer es aprovechar las afirmaciones web-first que vienen con Expect y podemos decir que, inicialmente, esperamos que no haya ningún elemento de lienzo. Luego queremos hacer clic en el botón y luego esperamos que haya un elemento de lienzo y que ya no haya ningún elemento de lienzo. Y aquí ves que todas estas instrucciones son asíncronas. Tenemos que esperarlas. Esto parece código secuencial, aunque hay mucha espera incluida aquí. Entonces, este botón solo aparecerá después de unos segundos. Luego, el elemento de lienzo aparecerá inmediatamente, pero solo desaparecerá después de unos segundos. Y en PlayWrite, todo esto está integrado en la propia instrucción. Y creo que esta es una forma maravillosa de agilizar el código de prueba de extremo a extremo sin poner esperas forzadas y retrasos artificiales en todas partes. Y aquí ves que ahora tenemos dos pruebas pasadas y podemos romper esto haciendo esto, pero creo que es una forma hermosa y agradable. Así que podemos seguir adelante.

Y quiero mostrarte algo que también creo que es muy, muy genial. Así que arreglemos la prueba de nuevo porque ahora estaba rota. Entonces, lo que siempre puedes hacer en tus casos de prueba es jugar con la capa de red o con las partes internas de la carga de una página web en particular. Entonces, lo que ves aquí es que este caso de prueba obtiene el objeto de página en esta ejecución de prueba. Y aquí ves que podemos escuchar todas las solicitudes y respuestas que entran y salen. Entonces, si, por ejemplo, queremos verificar la calidad de un sitio web y evaluar que no haya 404 o 500 en las llamadas a la API, lo que podemos hacer es realizar una verificación rápida del estado. Si hay una respuesta de estado que es mayor o igual a 400, queremos recopilar la URL y agregarla a un array que aún no existe. Y creemos el array rápidamente, const not found y hagamos esto.

8. Aprovechando las API nativas del navegador

Short description:

Y tenemos que hacer push, aquí vamos. Y ahora tenemos que recargar la página porque ya estaba cargada. Y luego agregamos una afirmación rápida, esperamos que la longitud de no encontrados sea cero. Esto es todo lo que se necesita para asegurarse de que no haya solicitudes 404 en su página. Nuestra prueba de confetti está ralentizando un poco las cosas ahora, pero parece que no tenemos ningún recurso 404 o 500 en nuestros pequeños sitios web locales. También puedes comenzar a bloquear solicitudes para acelerar tus pruebas de extremo a extremo. Por último, quiero mostrarte cómo puedes aprovechar las API nativas del navegador para asegurarte de que tu sitio web sea lo suficientemente rápido.

Y tenemos que hacer push, aquí vamos.

Y ahora tenemos que recargar la página porque ya estaba cargada.

Y luego agregamos una afirmación rápida, esperamos que la longitud de no encontrados sea cero.

Esto es todo lo que se necesita para asegurarse de que no haya solicitudes 404 en su página.

Entonces ahora ejecutamos este caso de prueba nuevamente.

Veamos qué sucede aquí.

Nuestra prueba de confetti está ralentizando un poco las cosas ahora, pero parece que no tenemos ningún recurso 404 o 500 en nuestros pequeños sitios web locales.

También puedes hacer más cosas.

Puedes comenzar a bloquear solicitudes.

Por ejemplo, si quieres acelerar tus pruebas de extremo a extremo bloqueando fuentes o bloqueando el seguimiento o bloqueando solicitudes de terceros, porque no son necesarias en tu conjunto de pruebas de extremo a extremo en este momento, también puedes hacerlo con todas las funciones internas que Playwright te proporciona en el objeto de página.

Y por último, quiero mostrarte cómo puedes aprovechar las API nativas del navegador para asegurarte, por ejemplo, de que tu sitio web sea lo suficientemente rápido.

Entonces, lo que ves aquí es que uso la función de evaluación de página, que es la forma de implementar tus propios agregadores de datos dentro de este sitio web en particular.

Playwright ya proporciona mucha funcionalidad.

Pero si hay algo que te falta y quieres conectarte al contexto del sitio web en particular, siempre puedes usar page evaluate y darle una función que se ejecute en el contexto de este caso de prueba web en este sitio web en particular.

Entonces, lo que ves aquí es que estoy usando page evaluate e instruyendo a un nuevo observador de rendimiento que averigüe la métrica de mayor contenido visible, que luego se pasa de vuelta al alcance de prueba.

Y lo que ahora podemos hacer es esperar y estoy convirtiendo LCP en un número porque ahora es una cadena para que sea menor que, no sé, tomemos 800 milisegundos aquí.

Ejecutemos esto.

Veamos si es lo suficientemente rápido en mi máquina local aquí.

Esto parece caché.

Veamos.

Aquí vamos.

Genial.

Y estas fueron solo algunas cosas que quería mostrarte sobre cómo podemos comenzar con Playwright, ejecutándolo en la línea de comandos.

Si la extensión de VS Code no es lo tuyo.

Así que terminemos esto.

Realmente Playwright viene con mucha funcionalidad, incluye esperas automáticas, capturas de pantalla de referencia, el ejecutor de pruebas es agradable, reintentos, trazas, extensión de VS Code, inspector de depuración, entrenador y capturas de imágenes.

Realmente hay muchas funcionalidades allí y el equipo está lanzando muchas cosas.

Así que estate atento.

9. Mejores prácticas para pruebas y monitoreo

Short description:

Los scripts cortos e idempotentes funcionan mejor para las pruebas y el monitoreo. Divida el flujo de la cuenta de usuario en diferentes pruebas para la paralelización. Tenga pruebas separadas para las operaciones de inicio de sesión, actualización y eliminación. Limpie después de cada caso de prueba para evitar el desorden en la base de datos.

Pero en Checkli volvemos a ejecutar Playwright cada pocos minutos para nuestros clientes, y solo quiero compartir algunas mejores prácticas comunes. Así que primero que nada, lo que hemos visto es que los scripts cortos e idempotentes suelen funcionar mejor para el caso de uso de pruebas y monitoreo. En lugar de tener y probar todo el flujo de la cuenta de usuario, lo que generalmente quieres hacer es dividirlo en diferentes pruebas para facilitar la paralelización. Por lo tanto, lo que a menudo recomendamos a todos nuestros clientes es que deben crear una prueba de inicio de sesión, una de actualización y una de eliminación para sus propiedades o recursos de cuenta, para que todas estas cosas puedan ejecutarse en paralelo. Y esto también significa que si una falla, realmente sabes qué falló, qué está sucediendo, y obtienes un pequeño mensaje agradable, `Hey, este caso de prueba en particular falló`, y también es muy importante que este tipo de scripts sean idempotentes. ¿Qué significa eso? Creo que es una palabra muy elegante. Pero básicamente significa que tus casos de prueba se limpian a sí mismos para que puedas ejecutarlos repetidamente, lo cual es muy importante para el caso de uso de monitoreo. Entonces, cada vez que crees algo, tu caso de prueba debe limpiar después de sí mismo para no llenar una base de datos, y este tipo de casos de prueba deben ejecutarse en todo momento. Y lo que hacemos exactamente es combinar nuestras pruebas de extremo a extremo con llamadas de API de bajo nivel. Por ejemplo, si creamos un recurso con la interfaz de usuario de extremo a extremo, generalmente tenemos scripts de limpieza que luego eliminan todos los recursos que se crearon durante pruebas específicas en el nivel de API. Y esto lo ejecutamos con mucho éxito. Y como una idea aquí hoy, me gustaría compartir que sería genial si comenzamos a tratar nuestras interfaces de usuario como tratamos nuestras API. Por ejemplo, en software, siempre hablamos de tiempo de actividad de la API, ¿verdad? Los proveedores de API siempre están muy orgullosos del número de nueves en la disponibilidad. Esta API ahora está activa durante el 99.99999% del tiempo. Pero siento que estamos ignorando o no estamos tomando en serio la capa de front-end. Y creo que toda la aplicación que estamos construyendo debería ser probada todo el tiempo. Y sería bueno si pudiéramos tener las mismas estadísticas para la creación de cuentas, el inicio de sesión de cuentas, la actualización de cuentas y la eliminación de cuentas. Sería genial ver que, hey, mi creación de cuenta probada con un navegador funciona el 99.999% del tiempo. Y creo que eso sería un buen resultado si llegamos a eso. Y honestamente, la tecnología que usamos realmente no importa aquí. Si usas Cypress, usa Playwright, usa Perpetrator, pero simplemente prueba todas tus propiedades porque descubrí, desafortunadamente, suficientes errores en la capa de interfaz de usuario. Y creo que podemos hacerlo mejor como industria, pero probablemente no tenga que decírtelo porque estamos aquí en la Cumbre de test.js. Así que con eso, creo que el monitoreo de extremo a extremo realmente debería ser tu red de seguridad y tu yo futuro te lo agradecerá. Mi yo futuro ya lo hace y ahora me estoy quedando sin batería. Así que gracias a todos por escuchar. Si quieres ponerte en contacto, mi nombre es Stefan Jueris y si tienes alguna pregunta, siempre estoy disponible para responder. Así que con eso, nos hablamos muy, muy pronto.

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

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
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
TestJS Summit 2022TestJS Summit 2022
20 min
Testing Web Applications with Playwright
Top Content
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.

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
Top Content
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
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
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.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
React Summit US 2023React Summit US 2023
96 min
Build a powerful DataGrid in few hours with Ag Grid
WorkshopFree
Does your React app need to efficiently display lots (and lots) of data in a grid? Do your users want to be able to search, sort, filter, and edit data? AG Grid is the best JavaScript grid in the world and is packed with features, highly performant, and extensible. In this workshop, you’ll learn how to get started with AG Grid, how we can enable sorting and filtering of data in the grid, cell rendering, and more. You will walk away from this free 3-hour workshop equipped with the knowledge for implementing AG Grid into your React application.
We all know that rolling our own grid solution is not easy, and let's be honest, is not something that we should be working on. We are focused on building a product and driving forward innovation. In this workshop, you'll see just how easy it is to get started with AG Grid.
Prerequisites: Basic React and JavaScript
Workshop level: Beginner
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.