Playwright Test Runner

Hola a todos, mi nombre es Andrej, y hoy me gustaría presentarles el nuevo Playwright Test Runner. Así que empecemos. Primero que nada, ¿qué es Playwright Test? Bueno, es un marco de pruebas web testing framework escrito en Node.js, lo que básicamente significa que puedes escribir tus pruebas en JavaScript o TypeScript. Ahora es gratuito y de código abierto y patrocinado por Microsoft y ya se utiliza ampliamente en la industria. Ahora esto está bien, pero no responde a la gran pregunta que se cierne. Entonces, ¿por qué hicimos otro Test Runner? Honestamente, no teníamos la intención de hacerlo. Hay muchos corredores de pruebas diferentes en JavaScript, resulta que todos son corredores de unit test. Mientras que en las pruebas de extremo a extremo, hay muchos desafíos muy difíciles. Entonces, por ejemplo, quieres que tu corredor de pruebas soporte pruebas multi-navegador de serie. También quieres que estén paralelizadas de serie. Y quieres que estén aisladas, y Playwright, por ejemplo, tiene un conjunto de APIs únicas para asegurarse de que el aislamiento de las pruebas sea rápido y fiable. Y por supuesto, queremos que se utilicen. Y por último, pero no menos importante, la historia muestra que las pruebas de extremo a extremo requieren un nivel de flexibilidad y configuración loca, porque hay muchas configuraciones diferentes que queremos usar para ejecutar la misma prueba. Y Vivio se inspiró en los fixtures de PyTest, por lo que los fixtures están implementados en PlayWriteTest también. Así que PlayWriteTest es nuestra respuesta a las pruebas de extremo a extremo. Y este es el corredor de pruebas que se construyó específicamente para abordar todas las necesidades de pruebas de extremo a extremo.

Así que tenemos bastante de qué hablar en esta charla, y solo tenemos 20 minutos. Así que vamos a saltar directamente al primer capítulo, que es comenzar. Bueno, la mejor manera de mostrar algo es realmente mostrar algo. Así que permíteme saltar a mi terminal y crearé una nueva carpeta. Y empezaré desde cero e inicializaré un nuevo proyecto npm. Ahora hagamos npm init PlayWrite. Y lo que esto hace es configurar este proyecto para usar PlayWrite para mí. Mientras lo hace, me hará todo tipo de preguntas diferentes. Por ejemplo, ¿qué idioma quiero usar para escribir pruebas? Y es TypeScript porque en realidad no necesito configurar nada adicional, puedo simplemente escribir mis pruebas en TypeScript y serán transpiladas a JavaScript y se ejecutarán sin problemas, no necesito hacer Babel y Webpack o cualquier cosa. Me preguntará dónde poner mis pruebas, por supuesto quiero tener un flujo de trabajo de GitHub Actions, y sí, los ejemplos son buenos. Así que una vez que respondí todas las preguntas, instala todas las dependencias para el NPM, descarga todos los navegadores, ya los tengo descargados así que estos se han reutilizado. Y ahora estoy aquí con un montón de fuentes pre-creadas para mí.

OK ¿qué más tenemos? Tenemos este archivo de configuración. Esta vez voy a usar Wim para entrar en él. Ahora este es un archivo generado y tiene muchos comentarios por lo que puedes fácilmente revisarlo y entender qué está pasando. No necesitamos nada de esto. Quiero centrarme en este array de proyectos. Ahora los proyectos son como entornos. Solo tenemos una prueba y queremos ejecutar esta prueba en diferentes navegadores como Firefox o Chrome y para eso son los proyectos. Así que aquí tenemos cinco proyectos preconfigurados para nosotros. Tenemos Chrome de escritorio, Firefox de escritorio, Safari de escritorio. Todo bien. E incluso tenemos emulación móvil para Pixel 5 que es Android y iPhone 12 que es un Safari móvil. Así que tenemos una prueba y cinco proyectos lo que significa que vamos a ejecutar cinco veces esta prueba. Veamos cómo sucede esto. Para ejecutar pruebas puedo hacer mbxplaywrite test y cuando ejecuto este comando se ejecutan cinco pruebas usando cinco trabajadores. Así que escribiremos que en realidad se ejecutan cinco pruebas lo cual es bueno. Pero lo otro importante es que en realidad se utilizan cinco trabajadores. Así que todas estas ejecuciones de pruebas están sucediendo en paralelo y en realidad solo toman ocho segundos lo cual es bastante rápido. Vale, así que de la caja no hicimos nada. Ya obtuvimos ejecuciones de pruebas en diferentes navegadores, nosotros

Entonces, podemos instalar Playwright en proyectos con este script de ayuda npm init playwright. Y una vez que tenemos instalado Playwright, podemos ejecutar pruebas con npx playwright test. Y todo se ejecuta en paralelo. Y así es como se ve realmente Playwright. Es una API muy simple e intuitiva. Y esta es una única API para controlar todos los diferentes navegadores. Y por supuesto tenemos reporteros, tenemos un informe LUR, tenemos un informe HTML, incluso tenemos el informe JUnit si te gusta este tipo de cosas.

Bueno, acabamos de jugar con cómo empezar. Vamos a crear algunas pruebas nuevas. Y ahora quiero mostrarte una cosa nueva que se llama Code-Gen. Para esto, voy a limpiar mi pantalla. Haré mpxplaywrite code-gen y guardaré los resultados de lo que voy a generar en github.spec.gs. Al hacerlo, se abren dos ventanas. La primera ventana, la ventana del navegador, es solo una ventana de Chrome normal, mientras que la segunda es este Inspector de Playwright, y hablaremos de él un poco más tarde, y tiene este sombrío botón rojo de grabación resaltado. Ahora, todo lo que hago dentro del navegador es grabado por el grabador, y acabo de navegar a Microsoft, y tengo esta página code de navegación. Así que puedo seguir interactuando con mi página web. Puedo decir Playwright, espera a que busque, pulsa el botón Playwright. De hecho, en la página web tengo este cuadro negro con texto blanco debajo de mi cursor. Así que esto me muestra el selector que se usará mientras interactúo con la página. Así que pulsaré en problemas, y seguiré adelante. Vamos a hacer clic en Pawel. Esto es suficiente. Puedo apagar la grabación y cerrar mi navegador. Ahora, veamos si realmente hemos grabado cosas. Tenemos nuestro script, lo cual es bueno. Pero, ¿funciona? Entonces, para asegurarme de que realmente funciona, puedo ejecutar solo este archivo de github y de esta manera realmente filtro por nombre de archivo. Pero tenemos varios proyectos. No los necesito por ahora. Solo quiero ejecutar en desktop chrome, por ejemplo. Y realmente quiero que

OK. Entonces, es realmente fácil crear una nueva prueba con Codegen, y si quiero cambiar algo, siempre puedo ir y saltar a mi editor de elección y cambiar ciertas líneas aquí y allá.

Ahora, supongamos que esta prueba en realidad no funciona. ¿Cómo la debug? Bueno, resulta que es bastante fácil. Solo puedo decir, dash dash debug para mi prueba. Y de nuevo, abrirá dos ventanas para mí. Esta es una ventana del navegador que ejecutará esta prueba. Y la redimensionaré para descubrir la segunda ventana, que es una ventana del inspector de Playwright. Así que no tuve la oportunidad de mostrarte este inspector de Playwright UI, así que aquí estoy. Déjame mostrarte alrededor. Tenemos cuatro partes de esta UI. En el centro mismo tenemos este código fuente de la prueba que estás debugging. Y tenemos una línea de ejecución resaltada, que en realidad está pausada en la posición actual de Playwright. Puedo controlar esta línea de ejecución usando el panel de control aquí. Por ejemplo, puedo hacer clic en step over para saltar este comando. Y a medida que paso por encima de la navegación, la página de Playwright en mi navegador navega. Aquí abajo tengo el registro de todas las acciones que Playwright está haciendo en realidad. Puedo ver que la página go to tuvo éxito. Hay una marca de verificación verde. Solo tomó dos segundos. Y estamos haciendo page click, y estamos pausados. Y puedes expandir estas acciones y ver qué está pasando en realidad dentro. Y page click ya está pre-expandido para mí. Y puedo ver todo tipo de cosas que están sucediendo aquí. Y, por ejemplo, Playwright estaba esperando que el elemento estuviera visible, y habilitado, y estable.

Y se desplaza a la vista, y hace todo tipo de cosas. Y esta es la auto-ponderación incorporada, y así es como realmente nos aseguramos de que todos tus clics estén sucediendo de verdad. Incluso nos aseguramos de que el elemento reciba eventos de puntero en una ubicación determinada. Y aquí es donde estamos a punto de hacer clic, y puedes ver esta ubicación en la ventana del navegador marcada con un punto rojo. Así que aquí es donde estamos apuntando ahora.

Vale. Por último, pero no menos importante, tenemos esta cuarta sección que es un selector de juegos. Y actualmente está resaltando este marcador de posición, encuentra el repositorio. Este es el selector que se utilizará para la acción que está en pausa en este momento. Puedo cambiar esto y decir, por ejemplo, texto igual a TS lib. Y a medida que cambio y escribo diferentes selectores aquí, los elementos se seleccionan en el navegador página. Y esto es genial, pero este botón Explorar es aún más genial. Así que cuando hago clic en él, se activará la ventana de Chrome. ¡Bam! Ahora, a medida que paso el cursor sobre las diferentes partes de la página, puedo ver diferentes selectores aquí en este cuadro negro debajo de mi cursor. Y cuando hago clic en este elemento, por ejemplo, el selector se pega en este input campo. Así que puedo refinarlo aún más, por ejemplo. O simplemente puedo copiarlo y pegarlo en mi editor. Y este es el Inspector de PlayWrite, y así es como hacemos debug pruebas en PlayWrite. Volvamos a nuestra presentación.

Así que acabamos de ver cómo podemos generar pruebas con MBX PlayWrite CodeGen. Y vimos el Inspector de PlayWrite, que es tan fácil de abrir como pasar el "-debug flag a tu comando. Y una vez que lo haces, se te presenta esta hermosa y magnífica UI que te muestra todo lo que necesitas saber sobre tu prueba. Vale. Así que todo esto es muy genial, pero todo esto sucedió localmente en mi máquina. Lo que significa que la prueba estaba fallando localmente y tenía una reproducción muy agradable. Puedo reproducir el fallo y puedo debug usando el Inspector de PlayWrite. Pero, ¿qué haría si este fallo ocurriera realmente en algún lugar de la cloud y no tuviera ninguna forma de reproducirlo localmente? Por supuesto, puedo tomar una captura de pantalla, o por ejemplo, grabar un video de toda la ejecución. Pero, ¿no sería genial si pudiera realmente deep dive en los aspectos internos del navegador, en la console del navegador o las acciones de la red? O, ya sabes, ir e incluso quizás deep dive en el DOM de la página? Después de cada acción de mi ejecución de prueba. Resulta que esto es realmente posible. Y esto es posible con algo llamado trazado de PlayWrite.

Permíteme contarte sobre el trazado de Playwright. Pero antes de hablar realmente sobre el trazado, un poco de terminología. Primero que nada, llamamos a esto depuración post-mortem. Porque esta es una depuración de un fallo de prueba que ocurre en algún lugar lejano. Y no hay una forma básica para que yo lo reproduzca localmente. Entonces, para depurar este tipo de fallos, y estos son fallos muy desagradables. Usualmente usamos cosas como artefactos de prueba, que son cualquier subproducto de la ejecución de pruebas. Cosas como registros o capturas de pantalla de videos, todos estos cuentan como artefactos de prueba.

Ahora, en Playwright, en realidad tenemos este tipo único de artefacto, que se llama trazado. Y resulta que el trazado por sí mismo es mucho más capaz que los videos y las capturas de pantalla combinados. Así que permíteme explicarte qué es y te mostraré cómo funciona. Entonces, el trazado de Playwright es esta tecnología que consta de dos partes. Primero están estos archivos trace.zip y estos son en realidad los artefactos. Y este es un formato de archivo portátil que tiene toda la información sobre la ejecución de la prueba de Playwright como acciones, eventos, screencast, registro de red, registro de consola y capturas de DOM para cada una de las acciones. Y luego también tenemos TraceViewer y TraceViewer es este programa que en realidad viene con Playwright que te permite mirar estos archivos de trazado y explorarlos. Y desde Playwright v.1.17, incluso tenemos Trace.playwright.dev, un sitio web especial donde puedes soltar todos los trazados y se te presentarán.

Así que permíteme darte una demostración de cómo se ve. Así que aquí convenientemente tengo un repositorio creado específicamente para esta presentación. Pero aquí en este repositorio tengo una acción y está fallando. Así que vamos a explorar. Por alguna razón algo está, está agotando el tiempo y incluso me dice que vaya y abra el rastro. Así que realmente voy a hacer esto. Iré al resumen y en las acciones de GitHub tenemos todos los artefactos cargados, y si en realidad usas una acción de GitHub que podemos preconfigurar para ti subirá todos los artefactos automáticamente. Así que puedo descargar este archivo de trazado. Lo tengo aquí, lo descomprimo, y este es el archivo de trazado y usaré este archivo trace.playwright.def y simplemente tomaré este trazado y lo arrastraré y lo soltaré sobre el área. Esta es la URUI de trazado. Así que muchas cosas están sucediendo aquí, así que permíteme mostrarte alrededor. Aquí arriba tenemos una línea de tiempo y puedes pasar el cursor sobre la línea de tiempo y desplazarte sobre ella para ver cómo están sucediendo las cosas dentro de tu página web. Esto es prácticamente como un screencast pero el screencast en realidad se superpone con todas las acciones como estas barras por encima del screencast. Estas son las acciones.

Entonces, por ejemplo, aquí arriba, puedo ver que la navegación tardó alrededor de 600 milisegundos. Esta línea azul es una página que va a llamar y así sucesivamente puedo ver aquí hay un clic, aquí hay un expect, aquí hay otro clic, y así sucesivamente.

Ahora, en el lado izquierdo tengo la lista de todas las acciones en mi script en orden cronológico y Esto es realmente navegable con el teclado. Puedo subir y bajar para seleccionar diferentes acciones y Para cada acción en el lado derecho. Oops, lo siento Tengo este panel con toda la información sobre esta acción y Tengo todos los mensajes de console que ocurren durante la ejecución de esta acción y E incluso toda la red que está sucediendo aquí Correcto. Así que la navegación es obviamente muy pesada en la red Y en el medio aquí Tenemos un Dom Snapshot. Así que esto no es una captura de pantalla Es una instantánea, lo que significa que es un HTML real CSS. Puedes desplazarte. Incluso puedes escribir En campos de entrada. No hay JavaScript, por lo que no reaccionará, pero aparte de eso, CSS hovers todas las cosas funcionan y Incluso puedes ir e inspeccionarlo con DevTools Así que aquí estoy, puedo usar DevTools para mirar en el DOM de GitHub Lo cual es muy agradable y me da capacidades ilimitadas ahora para clics y Con Navegaciones, nos gustan todas estas acciones que tenemos aquí y Bueno, por último, pero no menos importante, podemos ver que este último clic de página intentamos hacer clic en algo llamado lobo y Esta acción se agotó, así que, honestamente, no hay lobo en esta página. Así que es muy predecible Esto fue Traceviewer

Así que, por favor, usa trace.playwright.dev, es un sitio web muy agradable y una vez que lo hagas, tendrás esta hermosa UI con todas las cosas buenas y campanas y silbatos que te mostré y Esto es todo para esta presentación resumen

Así que Playwright Test Bueno, en primer lugar, puedes instalarlo con npm playwright Puedes autorizar nuevas pruebas con code.gen Puedes debug tus pruebas con inspector y puedes hacer depuración post-mortem con trazado así que Si usas Playwright Test, básicamente estás cubierto en todas tus etapas de vida como autor de pruebas Si te gusta lo que has visto Por favor, dirígete a nuestra documentation para aprender más sobre Playwright También estamos presentes en canales sociales. Por favor Únete a nuestro slack. Somos muy activos allí y síguenos en Twitter, suscríbete a nuestro YouTube y Danos una estrella en GitHub Gracias por escuchar