Técnicas Avanzadas de Playwright para Pruebas Impecables

Hola a todos. Técnicas avanzadas de Playwright para pruebas impecables. Mi nombre es Debbie O'Brien y soy Principal Technical PM en Microsoft. Acabo de ser promovida y básicamente me estoy enfocando en Playwright y asegurando que la comunidad alrededor de Playwright sea increíble y que haya contenido increíble para que todos puedan aprender pruebas porque el objetivo es que todos deberían estar probando.

Soy una oradora internacional, profesora, YouTuber, colaboradora de Open Source, y me encanta absolutamente el deporte. Acabo de recibir el OK para volver a correr después de tener gemelos. Así que, sí, síganme si quieren ver muchas fotos de mí corriendo y andando en bicicleta por la isla. Pero vamos a hablar de Playwright.

Entonces, ¿qué es Playwright? Para aquellos que no lo saben, Playwright es una herramienta confiable de pruebas de extremo a extremo para aplicaciones web modernas, y funciona en cualquier navegador, cualquier plataforma con una API. Las pruebas se ejecutan en aislamiento completo, por lo que no hay necesidad de limpiar y una no pasa de una prueba a otra. Todo está aislado. Eso es realmente genial y lo hace mucho más fácil. Y las pruebas se ejecutan realmente rápido. ¿Qué hay de rápido en estos días, verdad? Bueno, las pruebas se ejecutan rápido, así que eso es realmente genial. Tenemos algunas herramientas poderosas. Podemos hacer cosas como, ya sabes, usar un generador de código para simplemente grabar tu prueba simplemente, como, jugando con el sitio web. Muchas cosas geniales, y también es multilenguaje. Así que puedes usar JavaScript, TypeScript o podrías usar Python, Java y .NET.

Entonces, ¿por qué deberías usar Playwright? Bueno, Playwright espera automáticamente los elementos. Así que si estás usando Playwright correctamente, básicamente, va a esperar a que los elementos aparezcan en la página. También reintenta las afirmaciones. Puedes usar iFrames, Shadow DOM. Como mencioné antes, las pruebas están aisladas y luego las pruebas se ejecutan en paralelo por defecto, y eso es lo que lo hace mucho más rápido. También puedes fragmentar. Si estás en la escalabilidad, necesitas fragmentar en múltiples máquinas, eso simplemente funciona. Y luego, por supuesto, nuestras herramientas, tenemos la extensión de VS Code. Tenemos CodeGen para generar tu código. Tenemos un selector de localizadores para encontrar el localizador. Un localizador es el elemento en la página, ¿verdad?, el botón.

Tenemos modo UI. Probablemente te mostraré algunas cosas del modo UI hoy. Y luego tenemos informes HTML, visor de trazas y GitHub Actions. Funciona directamente con GitHub Actions. Pero, por supuesto, podrías usar cualquier proveedor de CI.

Así que vamos a sumergirnos en algunos consejos. Simulación de API, pruebas de fecha y hora, configuración de pruebas y un poco de la CLI. Vamos a entrar.

Así que, un par de consejos, realmente, realmente importantes. Usa localizadores. Así que los localizadores tienen la espera automática y la capacidad de reintento. Así que es realmente, realmente, realmente importante usar los localizadores adecuados. Eso significa que intenta no, tanto como sea posible, no usar localizadores CSS. Definitivamente, no uses XPath. Así que para encontrar un elemento en la página, usa lo que llamamos localizadores.

Y tenemos atributos orientados al usuario. Queremos priorizar eso. Así que tenemos cosas como getByRole. Por ejemplo, getByRole de button con el nombre submit es mucho más orientado al usuario. Es mucho mejor para el usuario. El usuario lo ve, ¿verdad?, en lugar de getByTestID. Podrías usar getByTestID, pero recomendamos atributos orientados al usuario primero. Así que sí, usa localizadores, espera automática y capacidad de reintento. Usa las afirmaciones de playwright. Así que en lugar de decir to be, usa las afirmaciones de playwright para tener texto, ser visible, etcétera, porque estos son de reintento automático, y eso asegurará menos inestabilidad en tus pruebas.

Así que aquí tengo un ejemplo. Estoy usando un test ID en este ejemplo. Espera que page.getByTestID de status tenga el texto submitted. Anotaciones. Esto es realmente genial.

¿Estás usando anotaciones? Este es un informe de Playwright, y cuando usas anotaciones, obtienes las anotaciones en el informe. También las obtienes en el modo UI en el visor de trazas. Así que aquí en las anotaciones, tengo un problema. Tengo problemas relacionados. Así que podría haber algo pasando con esta prueba, y quieres que esa información se vea en un informe. Y este es el lugar perfecto para hacerlo. Así que usa anotaciones.

Ahora, para agregar una anotación, todo lo que tienes que hacer es simplemente poner la anotación justo después del nombre de la prueba. Así que llamo a la prueba usar anotaciones. Terrible nombre, pero la prueba podría ser lo que sea. Y luego simplemente abre esas llaves y escribe una anotación. La anotación es un array, por lo que acepta más de un tipo. Y puedes poner tu propio tipo o descripción, ¿verdad? Podrías decir tipo Debbie, ¿verdad? Lo que quieras. Así que eso es realmente genial, y también son clicables.

Así que en el informe, simplemente haces clic y vas directamente a ese problema. Y no tiene que ser problemas. Podría ser lo que quieras. Así que aquí hay una pequeña idea que he creado solo para mostrarte cómo se ve. Así que aquí, tengo una prueba. Voy a ejecutar esta prueba. Y lo que va a pasar es que va a ejecutar todas las pruebas en la lista de gestión. Ahora, tengo una prueba aquí. Puedes ver que no se está ejecutando. ¿Por qué es eso? Vamos a echar un vistazo a la pestaña de anotaciones. Y eso es porque he puesto un Fix Me. Así que Fix Me también se llama una anotación. Así que hay algo mal con esta prueba. Necesito que alguien la arregle. Así que voy a poner Fix Me. Ahora, la última prueba aquí, está volviéndose un poco lenta, pero mira, falla.

De hecho, tengo un test.fail allí. Así que la anotación aparece como fail. Y tengo el problema para mostrar a cualquiera que esté ejecutando esta prueba que hay un problema. Esta prueba va a fallar hasta que alguien solucione ese problema. Y puedes ver aquí, tengo test.fail. Y eso significa que no va a estropear CI, pero la prueba fallará. Quiero que falle. Y tengo mi anotación allí para que podamos mantener un control sobre eso y luego filtrar por pruebas fallidas más adelante, etcétera. Así que las anotaciones son muy geniales.

Pasos de prueba. Los pasos de prueba son realmente agradables, especialmente si tienes una prueba realmente larga. Quieres simplemente poner ciertas cosas en un pequeño paso. Así que aquí hay un paso de prueba.createFirstToDo. Y luego lo lleno y hago ese tipo de cosas. Y luego tengo otro paso, crear el segundo to do. Y por supuesto, esto podría ser una función, pero este es un ejemplo de, lo tengo en mi película donde tengo muchas cosas sucediendo y lo divido en pasos de prueba. Hace que sea mucho más fácil de ver en el modo UI y también mucho más fácil en el visor de trazas y en el informe en sí. Así que aquí en el informe, por ejemplo, simplemente voy a createFirstToDo, luego espero el texto superior, crear el segundo to do, bam. Y realmente no me importan los detalles de implementación, pero puedo simplemente abrir eso si realmente quisiera y ver más de eso. Así que es una forma agradable de hacer eso. Así que te animo a usar pasos de prueba. Y por supuesto, también puedes encerrar los pasos de prueba. Así que podrías decir box.true. Y lo que esto hace es básicamente detener el mensaje de error de darte demasiada información. Así que aquí tengo el mensaje de error, el nuevo todo.fill, y no sé a dónde ir, ¿verdad? Hay dos pequeños errores allí. Pero con los pasos encerrados, básicamente está diciendo que los errores están en el getByPlaceholder, lo que necesita ser hecho. Así que puedo ir directamente a esa área para arreglar eso en lugar de enfocarme en demasiado. Así que esa es otra opción también, encerrar tus pasos.

Bien, vamos a entrar en la simulación de API. La simulación de API es bastante divertida. Y hay mucho tipo de cosas como deberíamos simular nuestras APIs y cosas así. Y obviamente quieres ejecutar pruebas de extremo a extremo. Quieres probar todo lo posible. Pero hay momentos en los que necesitarás simular tu API y eso está totalmente bien. Así que te voy a mostrar haciendo una demostración, voy a usar el modo UI.

En caso de que no lo sepas, NPX Playwright test dash dash UI es lo que va a abrir el modo UI. Así que una vez que hago eso, tengo el modo UI abierto y todas mis pruebas están aquí. Ahora tengo esta prueba en la página de detalles de la película. Así que aquí están los detalles de mi película, ¿verdad? Ahora esta película no va a cambiar mucho. Es muy estática, ¿verdad? El título no va a cambiar, el género no va a cambiar, la descripción, los personajes. Quiero decir, no deberían cambiar, ¿verdad? La película está terminada. Es un producto terminado, pero la calificación va a cambiar.

Y vamos a sacar eso para que puedas verlo más de cerca. Tengo una calificación de 7.02. Ahora esa calificación es constante. Así que mañana podría ser 7.03, ¿verdad? Entonces, ¿cómo probamos ese contenido dinámico como parte de esta página estática? Y ahí es donde quieres simular un poco la API porque realmente solo quieres asegurarte de que las estrellas aparezcan en la página. Entonces, ¿cómo haríamos eso? Bueno, básicamente en nuestra prueba aquí, tengo un wait page.root allí en la línea ocho, y solo estoy poniendo en la raíz a la que iríamos, que es el ID de la película. Así que cuando golpeo la raíz del ID de esa película, quiero que vayas y obtengas ese JSON, ¿verdad? Espera a que ese JSON regrese. Y luego quiero decir, bueno, Jason, quiero que el promedio de votos sea 7.02. Bien, ahora eso es lo mismo que es. Está bien, eso está bien. No te preocupes por eso por ahora. Y luego solo estoy verificando que realmente está allí, ¿verdad? Ahora, si entro en mi pestaña de red en el modo UI, realmente puedo echar un vistazo y puedo ver en el cuerpo de esto el 7.02, ¿verdad? Eso es correcto. Así que eso no tiene mucho sentido para ti porque estás como, ¿por qué estás simulando algo que es exactamente lo mismo que es, verdad? Puedo ver la API. El cuerpo de la API también es el mismo. Así que realmente no hay mucha diferencia aquí, ¿de acuerdo? Pero lo que queremos hacer es cambiarlo. Así que imaginemos, no sé, todos vieron esa película, todos pensaron que era increíble y obtuvimos un 10, ¿verdad? Así que 10 vino de la API con mi contenido estático. Mi prueba va a fallar porque va a estar buscando 7.

Obtuve un 10, mi prueba falló. Mira, el 10 se muestra allí. Eso es genial. Puedo ver que, ya sabes, a todos les encanta esta película, pero todo falló. Entonces, ¿cómo arreglo eso? Y ahí es básicamente donde quieres simular esa API. Y si miro mi cumplido, veo la forma en que me muestra que esto es el cumplido, puedo ir al cuerpo y me va a mostrar en la API, en el JSON, el promedio de votos es 10 porque eso es lo que simulé, ¿de acuerdo? Eso es lo que intercepté, fui y cambié eso. Y puedes ver que mi prueba está fallando porque está esperando el 7.02, que está en la prueba. Y por supuesto puedo volver a la prueba y cambiar eso a 10 y puedo dejar el promedio de votos de 10 si quisiera. Y obviamente tengo el modo de observación activado allí. Así que esa prueba se ejecuta automáticamente y mi prueba pasó y obtuve 10. Así que realmente no me importa cuál es el voto. Lo que me importa es que todo funcione como debería. Así es como lo haces.

Ahora también puedes, básicamente, ir a una ruta, por ejemplo, en este sitio web, no quiero acceder al sitio web de IMDB cada vez que quiero probar el sitio, pero quiero asegurarme de que el enlace sea clicable. Así que puedes ver aquí, cada película hace clic en el sitio web, hace clic en el sitio web de IMD. Y básicamente estoy diciendo, cuando quieras ir a ese sitio web, solo ve aquí en su lugar. Así que simulando, ¿verdad? Estoy simulando eso para que no acceda a ese sitio web, pero aún puedo probar que ese botón es clicable y va a ir a donde debería ir. Echemos un vistazo rápido a cómo harías eso. Así que en la misma prueba, de hecho tengo esto en la misma prueba. Mira, estoy usando test.stabs. Ves mis hermosas pruebas y asombrosas. Así que aquí, ¿verdad? Tengo mi página. Espero page.context, mira esa línea 77 y estoy diciendo ruta. Así que el sitio web de la película Twister. Así que cuando vayas al sitio web de las películas Twister, voy a crear una página HTML y una página simulada, ¿verdad? solo para demostrar que estoy yendo a esa página. Y luego básicamente solo, y lo mismo aquí, ¿verdad? para el sitio web de IMDB, cada vez que accedes, ves esa ruta, intercepítala y cúmplela con este cuerpo en su lugar, esta cosa simulada que estoy creando.

Puedes ver www.twistersmovie.com, ¿verdad? Así que es realmente, realmente genial. Así que sí, eso es API mocking. Así que echemos un vistazo a las pruebas de fecha y hora. ¿Cómo harías eso? Así que podrías querer probar algo como esto. Tenemos un reloj, ¿verdad?, y tenemos 16, 36, 52, y está contando hacia arriba, y está usando date.now.

Así que básicamente lo que tengo que hacer, tengo una función llamada startClock, tengo el const today, mi fecha, etcétera, y tengo un window addEventListener, load, start the clock, ¿verdad? Así que eso es básicamente mi reloj, HTML, y luego mi prueba, lo que va a hacer es básicamente estoy usando el page.clock, y estoy estableciendo una hora fija. Así que mi hora fija es una nueva fecha, a las 10 en punto de la mañana en esta fecha específica, y luego voy a mi sitio web del reloj. Así que setFixedTime devuelve una hora falsa fija en todo momento, ¿de acuerdo? Y luego básicamente ejecuto esta prueba, y solo me aseguro de que la hora sea las 10 en punto, eso pasa, y puedes ver en mi traza aquí, estoy ejecutando a través de la extensión de VS Code, y obtengo la vista de traza porque tengo eso configurado, y solo muestra, sí, va a las 10 en punto. Así que perfecto, realmente, realmente fácil de probar. Y puedes ver allí que la hora era en realidad 4.37, no son las 10 en punto, pero he simulado esa hora.

¿Qué tal avanzar manualmente el tiempo? Entonces puedes usar clockInstall para inicializar el reloj, y puedes decir quiero que inicialices en este momento específico. Así que estos temporizadores falsos se utilizan para controlar manualmente el flujo del tiempo en las pruebas, y puedes avanzarlo. Entonces puedes decir clock.pauseAt, por ejemplo, así que pausarlo a las 10 en punto, y luego puedes esperar que algo suceda. Y luego puedes adelantarlo 30 minutos, y esperar que suceda otra cosa, ¿verdad?

Así que esta es una prueba muy simple, pero podrías imaginar lo que estarías haciendo allí durante esos para asegurarte de que es a las 10, y luego es en otro momento, y luego está adelantando. Así que ejecutemos esa prueba para que puedas rápidamente ver cómo funciona súper rápido, y tienes como las ocho en punto, y tengo las 10 en punto, y luego estoy adelantando, y luego tengo las 10.30, así que muy, muy genial. Y luego te evita tener que esperar 30 minutos, ¿verdad?

Tienes cinco minutos para comprar. Amazon me hizo esto el otro día, cinco minutos para comprar, y yo estaba como volviéndome loco, y fui, ya sabes, ¿lo compro? Y no lo hice, y luego actualicé la página, y volvió a aparecer, así que genial. Entonces, ¿cómo probarías algo así sin tener que esperar cinco minutos?

Entonces harías el clock.install, y básicamente esperarías que la oferta flash sea visible, ¿verdad?, así que has inicializado el reloj, y luego esperas que algo sea visible, y luego avanzas cinco minutos porque entonces la oferta flash habrá terminado, y luego esperarás lo que sucede en esa página. Vas a esperar que la oferta expirada sea visible.

Así es como ejecutas esa prueba. Vamos a echar un vistazo y verlo en acción. Y mi prueba pasa, y puedes ver allí mi reloj inicializado. Tengo cinco, cuenta regresiva, y luego veo las ofertas flash allí, y luego básicamente avanzo, y obtengo mi oferta expirada. Así es como pruebas algo así. Nuevamente, asegúrate de que esté usando cosas como date.

now y no algo que venga del backend. Genial, ¿qué hay de configurar pruebas? Entonces, ¿qué pasa cuando tienes algo como un escenario de inicio de sesión, algo que quieres hacer antes de otras pruebas? Así que tengo una demo para mostrarte esto. Nuevamente, mpxplaywritetest-ui para abrir ese modo UI para que puedas ejecutar tus pruebas y jugar con las cosas mucho más fácilmente. Entonces, lo que vamos a hacer aquí es que tengo un sitio de películas donde necesito iniciar sesión para gestionar la lista de películas.

Así que mi sitio de películas necesita estar iniciado sesión, y básicamente puedo mirar aquí en el modo UI porque tengo el modo UI abierto. Si hago clic en esta pequeña cosa, puedo hacer clic en la prueba de configuración. Quiero mostrar, quiero ver eso. Así que está oculto para ti. Puedes hacer clic en eso para básicamente verlo. Así que tengo mi prueba de configuración, y voy y ejecuto. Ahora mira, solo ejecuto la prueba de agregar y eliminar una película, pero automáticamente ejecutó el inicio de sesión, la prueba de iniciar sesión al usuario, y luego fue y ejecutó la prueba de películas. Así que dependía de ello. La configuración se ejecutó primero. Y luego puedo ejecutar rápidamente.

Esta es la prueba realmente larga sobre agregar una película a mi lista de películas para que pueda crear las películas que quiero ver, etcétera. Así que aquí está, nuevamente, una prueba realmente, realmente genial. Mira cómo el modo UI, puedes ver realmente fácilmente cualquier cosa. Puedes hacer clic en algo allí y expandir esa línea de tiempo, lo cual es genial para depurar y verificar cosas. Mi código fuente está abajo. Tienes todo lo demás fácilmente a tu alcance. Entonces, ¿cómo funciona esa configuración? Bueno, básicamente, volvamos a VS Code, y puedes ver aquí mi archivo login.setup.

Entonces, ¿cómo funciona esa configuración? Bueno, básicamente, volvamos a VS Code, y puedes ver aquí mi archivo login.setup.ts. Básicamente, estoy usando import test as setup para que pueda llamarlo setup y quede claro para mí. Setup usa los logs in, y luego básicamente esa prueba de setup está en mi proyecto. Así que es un proyecto llamado setup, y mi prueba de Chrome con sesión iniciada, nuestro proyecto, cada prueba bajo ese proyecto depende de setup, y luego usa el estado de almacenamiento. El inicio de sesión es solo iniciar sesión como una prueba simple, pero todo es importante sobre el proyecto, las dependencias del proyecto se llama esto. Ahora, puedo desmarcar en modo UI, esa configuración, y puedo ejecutar esa prueba nuevamente, y ahora no está ejecutando la prueba con sesión iniciada porque ya la tiene guardada en el estado de almacenamiento. Y eso lo hace realmente rápido para el desarrollo. No necesitas estar ejecutando constantemente esa prueba de inicio de sesión todo el tiempo, se ejecuta una vez, inicia sesión, la desmarcas, y luego solo sigues ejecutando tus pruebas que necesitan el inicio de sesión, pero ya lo tiene iniciado porque ya lo has ejecutado una vez y está guardado en ese estado de almacenamiento. Y eso es dependencia del proyecto. Así que te animo mucho a que lo revises. No tiene que ser inicio de sesión, podría ser cualquier cosa. Podría ser crear una lista de películas, podría ser una que dependa de, no sé, lo que sea, pero hay muchas cosas realmente geniales que puedes hacer con las dependencias del proyecto.

Así que un par de cosas extra, tenemos la última falla para el CLI. Así que si no estás usando la extensión de VS Code, estás usando el CLI, esto es realmente genial. Básicamente puedes ejecutar la última prueba fallida. Así que en lugar de ejecutar 103 pruebas usando cinco trabajadores donde dos fallaron y 101 pasaron, básicamente puedes hacer npx playwright test dash dash last failed y solo ejecutará esas dos últimas pruebas que fallaron y ver luego cuando trabajaste en ellas, si han sido corregidas o todavía están fallando. Esa es una solución rápida.

También solo cambios para el CLI. Así que básicamente solo cambiarías, solo puedes ejecutar, solo ejecutas los archivos de prueba que han sido cambiados desde el último comentario. Así que aquí, por ejemplo, git status, estoy en la rama principal, cambios no preparados para comentario, nuestras pruebas solo cambiaron. Esta es mi prueba llamada solo cambio ejemplo. Y luego cuando ejecuto npx playwright test dash dash only changed, ejecuto una prueba usando un trabajador, y ejecuta esa prueba. Así que esto es realmente genial.

¿Y qué sigue? Bueno, básicamente Playwright es de código abierto y gratuito. Así que asegúrate de estar usando Playwright. Mira todas sus estrellas, ¿verdad? Nos encantan las estrellas. Estamos subiendo alto, pero aún queremos más estrellas. Así que estrellas en GitHub, realmente lo apreciamos. Las descargas de NPM están por las nubes. Es Playwright, es de Microsoft. Así que no tienes absolutamente ninguna excusa para no estar usando Playwright. Y tenemos embajadores increíbles. Te animo mucho a seguir a todas estas personas. Son increíbles y están creando contenido realmente genial por ahí. Puedes encontrar la página de embajadores bajo la pestaña de comunidad de nuestro sitio web. Y no olvides unirte a nuestro Discord de Playwright. Tenemos 14,000 miembros allí. Eso es una locura. Estoy muy impresionada. Y hay personas constantemente ayudándose mutuamente, compartiendo contenido. Y también hacemos happy hours allí. Así que ven y únete a nosotros en el escenario de Discord de Playwright. Y por supuesto, ¿estás listo para Playwright? Espero que todos hayan disfrutado esto.

Espero que te haya ayudado. Si eres nuevo en Playwright, asegúrate de unirte, solo pruébalo. Si eres un usuario avanzado, asegúrate de estar en un servidor de Discord y asegúrate de estar charlando con otros miembros de la comunidad y creando issues para cualquier cosa que tengas de la que no estés seguro.

Y básicamente, muchas gracias. Espero que hayas disfrutado la charla. Recuerda leer los documentos. Los documentos son realmente importantes. Sé que no los estás leyendo, deberías leerlos. Pero también, puedes visitar nuestro canal de YouTube donde publicamos algunos videos geniales y cosas así. Nuestro canal de Discord, como mencioné, estamos en Twitter.

Y si necesitas algo, solo envíame un correo electrónico, debbiobrian en Microsoft.com o visita mi sitio web, debbiop.codes. Muchas gracias a todos por escuchar y que disfruten el resto de las charlas. Adiós. Adiós.