¿Playwright puede hacer esto?

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

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.

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

FAQ

Stefan es un profesional que se dedica al desarrollo front-end y desarrollo de JavaScript, y es originario de Berlín, Alemania.

Playwright es una solución de pruebas muy inclusiva que permite realizar pruebas de extremo a extremo en todos los principales navegadores como Chromium, WebKit y Gecko Firefox, y se puede usar en sistemas operativos como Mac, Windows y Linux.

Stefan trabaja para una empresa llamada checkly, que se especializa en monitoreo de API y pruebas de extremo a extremo en la nube.

Playwright facilita la escritura de pruebas gracias a características como la espera automática y las afirmaciones web-first, además de permitir ejecuciones rápidas y paralelización de pruebas.

Playwright mejora las pruebas de extremo a extremo al ofrecer herramientas como la paralelización de pruebas, capturas de pantalla automáticas y regresión visual testing, haciendo las pruebas más rápidas y confiables.

Stefan destacó varias funcionalidades de Playwright, como su integración con VS Code, la capacidad de ejecutar pruebas en diferentes navegadores simultáneamente, y herramientas avanzadas de debugging y generación de pruebas desde la línea de comandos.

Antes de usar Playwright, Stefan escribió pruebas de interfaz de usuario y extremo a extremo utilizando Selenium, Phantom JS y Casper JS.

Para Stefan, las pruebas de extremo a extremo son cruciales porque permiten verificar que todos los componentes de un sitio web o aplicación, desde el navegador hasta la base de datos, funcionen correctamente en conjunto.

 Stefan Judis
Stefan Judis
23 min
03 Nov, 2022

Comments

Sign in or register to post your comment.
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: Playwright Can Do This?

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

Escalando con Remix y Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Escalando con Remix y Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Componentes de Full Stack
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Componentes de Full Stack
Top Content
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
Depuración de JS
React Summit 2023React Summit 2023
24 min
Depuración de JS
Top Content
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
Haciendo JavaScript en WebAssembly Rápido
JSNation Live 2021JSNation Live 2021
29 min
Haciendo JavaScript en WebAssembly Rápido
Top Content
WebAssembly enables optimizing JavaScript performance for different environments by deploying the JavaScript engine as a portable WebAssembly module. By making JavaScript on WebAssembly fast, instances can be created for each request, reducing latency and security risks. Initialization and runtime phases can be improved with tools like Wiser and snapshotting, resulting in faster startup times. Optimizing JavaScript performance in WebAssembly can be achieved through techniques like ahead-of-time compilation and inline caching. WebAssembly usage is growing outside the web, offering benefits like isolation and portability. Build sizes and snapshotting in WebAssembly depend on the application, and more information can be found on the Mozilla Hacks website and Bike Reliance site.
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.

Workshops on related topic

Domina los Patrones de JavaScript
JSNation 2024JSNation 2024
145 min
Domina los Patrones de JavaScript
Top Content
Featured Workshop
Adrian Hajdin
Adrian Hajdin
Durante esta masterclass, los participantes revisarán los patrones esenciales de JavaScript que todo desarrollador debería conocer. A través de ejercicios prácticos, ejemplos del mundo real y discusiones interactivas, los asistentes profundizarán su comprensión de las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables. Al final de la masterclass, los participantes ganarán una nueva confianza en su capacidad para escribir código JavaScript de alta calidad que resista el paso del tiempo.
Puntos Cubiertos:
1. Introducción a los Patrones de JavaScript2. Patrones Fundamentales3. Patrones de Creación de Objetos4. Patrones de Comportamiento5. Patrones Arquitectónicos6. Ejercicios Prácticos y Estudios de Caso
Cómo Ayudará a los Desarrolladores:
- Obtener una comprensión profunda de los patrones de JavaScript y sus aplicaciones en escenarios del mundo real- Aprender las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables- Mejorar las habilidades de resolución de problemas y la legibilidad del código- Mejorar la colaboración y la comunicación dentro de los equipos de desarrollo- Acelerar el crecimiento de la carrera y las oportunidades de avance en la industria del software
Uso de CodeMirror para construir un editor de JavaScript con Linting y AutoCompletado
React Day Berlin 2022React Day Berlin 2022
86 min
Uso de CodeMirror para construir un editor de JavaScript con Linting y AutoCompletado
Top Content
Workshop
Hussien Khayoon
Kahvi Patel
2 authors
Usar una biblioteca puede parecer fácil a primera vista, pero ¿cómo eliges la biblioteca correcta? ¿Cómo actualizas una existente? ¿Y cómo te abres camino a través de la documentación para encontrar lo que quieres?
En esta masterclass, discutiremos todos estos puntos finos mientras pasamos por un ejemplo general de construcción de un editor de código usando CodeMirror en React. Todo mientras compartimos algunas de las sutilezas que nuestro equipo aprendió sobre el uso de esta biblioteca y algunos problemas que encontramos.
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.
Desatando los Componentes del Servidor React: Una Inmersión Profunda en el Desarrollo Web de la Próxima Generación
React Day Berlin 2023React Day Berlin 2023
149 min
Desatando los Componentes del Servidor React: Una Inmersión Profunda en el Desarrollo Web de la Próxima Generación
Workshop
Maurice de Beijer
Maurice de Beijer
¡Prepárate para potenciar tus habilidades de desarrollo web con los Componentes del Servidor React! En esta inmersiva masterclass de 3 horas, desbloquearemos el potencial completo de esta tecnología revolucionaria y exploraremos cómo está transformando la forma en que los desarrolladores construyen aplicaciones web rápidas y eficientes.
Únete a nosotros mientras nos adentramos en el emocionante mundo de los Componentes del Servidor React, que combinan sin problemas el renderizado del lado del servidor con la interactividad del lado del cliente para un rendimiento y una experiencia de usuario inigualables. Obtendrás experiencia práctica a través de ejercicios prácticos, ejemplos del mundo real y orientación experta sobre cómo aprovechar el poder de los Componentes del Servidor en tus propios proyectos.
A lo largo de la masterclass, cubriremos temas esenciales, incluyendo:- Entender las diferencias entre los Componentes del Servidor y del Cliente- Implementar Componentes del Servidor para optimizar la obtención de datos y reducir el tamaño del paquete JavaScript- Integrar Componentes del Servidor y del Cliente para una experiencia de usuario fluida- Estrategias para pasar datos efectivamente entre componentes y gestionar el estado- Consejos y mejores prácticas para maximizar los beneficios de rendimiento de los Componentes del Servidor React
0 a Auth en una Hora Usando NodeJS SDK
Node Congress 2023Node Congress 2023
63 min
0 a Auth en una Hora Usando NodeJS SDK
WorkshopFree
Asaf Shen
Asaf Shen
La autenticación sin contraseña puede parecer compleja, pero es fácil de agregar a cualquier aplicación utilizando la herramienta adecuada.
Mejoraremos una aplicación JS de pila completa (backend de Node.JS + frontend de React) para autenticar usuarios con OAuth (inicio de sesión social) y contraseñas de un solo uso (correo electrónico), incluyendo:- Autenticación de usuario - Administrar interacciones de usuario, devolver JWT de sesión / actualización- Gestión y validación de sesiones - Almacenar la sesión para solicitudes de cliente posteriores, validar / actualizar sesiones
Al final del masterclass, también tocaremos otro enfoque para la autenticación de código utilizando Flujos Descope en el frontend (flujos de arrastrar y soltar), manteniendo solo la validación de sesión en el backend. Con esto, también mostraremos lo fácil que es habilitar la biometría y otros métodos de autenticación sin contraseña.
Tabla de contenidos- Una breve introducción a los conceptos básicos de autenticación- Codificación- Por qué importa la autenticación sin contraseña
Requisitos previos- IDE de tu elección- Node 18 o superior