¿Playwright puede hacer esto?

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.

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ó.

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.

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.

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.

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.

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.

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.

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.