Todos pueden escribir pruebas fácilmente

Todos pueden escribir pruebas fácilmente. Hola a todos, mi nombre es Debbie O'Brien, soy una PM técnica senior en Microsoft abogando por Playwright y asegurándome de que todos estén escribiendo pruebas. Eso pruebas es fácil, es divertido y es algo que cualquiera puede hacer. Así que, no tengan miedo porque al final de esta charla todos vamos a estar como oh dios mío necesito escribir pruebas ahora mismo. Así que, aguanten conmigo.

Sí, si quieren seguirme, debbs underscore O'Brien en Twitter o X o como quieran llamarlo estos días, así como todas las otras plataformas de redes sociales que existen, debbie.code es mi sitio web. Y vamos a hablar directamente sobre Playwright porque es por eso que estamos aquí hoy. Entonces, ¿qué es Playwright? Para aquellos de ustedes que no lo saben, nunca han oído hablar de Playwright. ¿Dónde han estado, en serio? Playwright es una prueba de extremo a extremo confiable para sus modernas web apps y funciona en cualquier navegador. Así que puedes estar en Windows y puedes probar en WebKit por ejemplo, una API, todas tus pruebas se ejecutan en aislamiento total, son realmente muy rápidas. Tenemos algunas herramientas increíbles de las que hablaremos hoy y es multilenguaje. Entonces, voy a mostrarles TypeScript, pero podrían escribir en JavaScript por supuesto o también en Python, Java o .NET.

Entonces, ¿por qué Playwright? Quiero decir, todas esas razones que acabo de mostrarles aquí, pero también hay muchas más, pero solo me voy a concentrar en esas y las vamos a repasar paso a paso. Y hay muchas otras razones, pero en serio, deberían estar usando Playwright en la historia.

Entonces, ¿qué significa auto-espera en Playwright? Por ejemplo, imagina que Playwright necesita hacer clic en un botón. Ahora, Playwright es como un usuario realmente, realmente rápido. Sabes que es realmente como usuarios frustrados rápidos. Entonces, ¿qué sucede cuando quizás el JavaScript no está listo o el botón no está cargado correctamente en el DOM y por lo tanto no es completamente clickeable? Bueno, Playwright esperará a que esté listo. Por lo tanto, está en auto-espera para ese elemento, lo que significa que no tienes que escribir ningún tiempo de espera artificial o algo por el estilo. Eso es realmente genial.

Entonces, si estás usando las aserciones de Playwright, reintentarán de forma predeterminada. ¿Qué significa eso? Bueno, imagina que esperas que el botón sea visible y va a esperar a que el botón realmente sea visible y lo reintentará hasta que lo sea o hasta que se agote el tiempo de espera. Entonces, reintentos de aserciones de forma predeterminada.

Ahora, ¿qué pasa si quieres probar iframes y shadow DOM? Bueno, simplemente funciona. No tienes que instalar nada, no hay nuevos plugins ni nada por el estilo. Puedes simplemente probar el iframe o probar el shadow DOM tal como probarías tus elementos normales en la página. Aislamiento de pruebas. Realmente importante. Mira los tubos de ensayo aquí. Ahora imagina que tu prueba está dentro de un tubo de ensayo y tu próxima prueba está dentro de otro tubo de ensayo. Bueno, es exactamente así. Entonces, nada de un tubo de ensayo irá al otro tubo de ensayo, lo que significa que más tarde si la prueba B falla, bueno, no es por la prueba A porque eso no tiene nada que ver con entre esas pruebas porque se están ejecutando en total aislamiento, y así es como Playwright funciona de forma predeterminada.

Paralelismo. Realmente importante. Tus pruebas se ejecutan en paralelo. Entonces, es como, imagina que tus pruebas son esos nadadores y simplemente están corriendo todo el camino hasta el final, ¿verdad? Imagina si tuvieras que esperar a que un nadador llegara al final y luego el siguiente nadador iría y luego el siguiente nadador iría. Eso sería realmente, realmente lento. Playwright no es lento. Playwright es super rápido. Funciona en paralelo por defecto. Con el sharding, también puedes escalar, así que imagina que estás en CI y quieres correr aún más rápido, entonces básicamente puedes dividir en shards a través de varias máquinas y tener tus pruebas, digamos cinco pruebas corren en una máquina, cinco en la otra, cinco en la otra, etc. Haciendo que tus pruebas se ejecuten aún más rápido. Probablemente sea mejor no usar esas máquinas. Deberías conseguir mejores máquinas que esas, pero ya sabes a qué me refiero.

Extensión de VS Code. Te animo encarecidamente a que utilices la extensión de VS Code porque entonces puedes escribir tus pruebas, reproducir tus pruebas, debug tus pruebas, abrir el visor de trazas, las opciones de selección de localizadores, la generación de código directamente desde VS Code, lo que hace que sea una experiencia realmente agradable.

Entonces, CodeGen. ¿Qué es CodeGen? Bueno, esto es realmente genial. Es una herramienta que te va a ayudar, especialmente cuando estás empezando a escribir tus pruebas para ahorrarte tener que empezar a escribir manualmente cada línea de código y no saber cuál es el elemento, cuál es el localizador. Playwright hará todo ese trabajo por ti. Así que cuando vayas a tu sitio web, lo uses como lo haría un usuario, empieces a hacer clic, rellenes todos esos forms y luego Playwright grabará tu acción de usuario, la pondrá en ese archivo. Si estás en VS Code, creará el archivo por ti, lo pondrá directamente en VS Code y luego tendrás la prueba escrita para ti. Luego sólo tienes que añadir tus aserciones por supuesto y luego afirmar que algo es visible o tiene un recuento o etc. Así que CodeGen, herramienta super genial. Y LocatorPicker, para esos momentos en los que necesitas escribir algo tú mismo y no sabes cuál es el localizador o incluso simplemente estás depurando y algo no funciona, estás como ¿qué está pasando con este elemento aquí? Puedes usar el LocatorPicker y puedes pasar el ratón sobre la página web y resaltará el localizador debajo y luego puedes básicamente copiar eso en tu código y solucionar tu problema o sabes escribir esa línea que no sabías cuál era el localizador. Esto es realmente útil porque usamos localizadores basados en roles, eso es lo que recomendamos. Así que si no estás acostumbrado a entender los roles accesibles de algo, no te preocupes porque no necesitas saber eso porque Playwright te dará el rol accesible correcto. Una vez que tu código es bueno, por supuesto.

UiMode, mi herramienta favorita, es simplemente increíble. Para usar UiMode, tendrás que abrir la terminal y poner npx Playwright test –ui y lo que hace es abrir esta ventana aquí y tiene como todas las pruebas en el lado izquierdo allí y puedes hacer clic y reproducir cada una de esas pruebas. Y luego aquí en el medio, tienes una instantánea del DOM - va a controlar las acciones y sabes qué, echaremos un vistazo a esto más tarde en una demostración, pero te animo encarecidamente a que uses UiMode y también viene con el modo Watch que es realmente genial. Informe HTML - así que puedes literalmente ver qué está pasando en tu prueba, cuántas pasaron, cuántas fallaron, cuántas fueron inestables, cuántas se saltaron y repasar todo el informe y puedes abrir y expandir eso y verlo en más detalle también. Y Trace Viewer - esto es algo similar a UiMode así que de nuevo tiene esa instantánea del DOM, tiene todo lo que necesitas saber y todas esas acciones y esto es realmente útil para depurar en CI. ¿Sabes que funciona en mi máquina? Luego lo envías a producción y algo falla en CI y estás como, ¿qué hago ahora? Trace Viewer tiene la respuesta. Descargas esa traza y depuras esa traza y averiguas exactamente qué pasó y cómo solucionarlo. GitHub Actions - así que Playwright viene con un GitHub Actions de serie que básicamente significa que puedes ejecutar tu prueba en CI sin siquiera tener que hacer ninguna configuración y eso es realmente, realmente genial. Así que por supuesto puedes ejecutar Playwright en cualquier proveedor de CI, pero te damos el GitHub Actions de serie y te facilita la vida. Así que te recomiendo encarecidamente que lo pruebes. Así que un par de best practices o tips. La primera es literalmente escribir pruebas de extremo a extremo. Y estoy muy serio al respecto. Hace muchos, muchos, muchos años la gente decía que las pruebas de extremo a extremo eran lentas, y que deberías escribir un montón de pruebas unitarias y luego un pequeño bit de pruebas de extremo a extremo. Pero el mundo ha cambiado. La tooling ha cambiado.

Todo ha cambiado. Las pruebas de extremo a extremo tooling son mucho más rápidas, son mucho más económicas que antes, por lo que no tienes que escribir tantas pruebas unitarias ahora. Y quieres que tu unidad, quieres que tu prueba esté lo más cerca posible del usuario. Por lo general, tus pruebas no están cerca del usuario, están cerca del código. Quieres que tus pruebas estén más cerca de lo que está haciendo el usuario, así que escribe esas pruebas de extremo a extremo. Así que si quieres llamarlas pruebas de integración o lo que sea, pero asegúrate de que estás escribiendo pruebas de extremo a extremo.

Si solo tienes tiempo para escribir una prueba, haz que sea una prueba de extremo a extremo. Mantén PlayWrite actualizado. Así que lanzamos una nueva versión de PlayWrite cada mes, y como, obviamente te damos algunas características realmente geniales, y estás como, oh, tal vez no necesito esa característica, está bien. Pero también como algunas correcciones de errores, y tal vez como, no tengo ningún error, está bien. Pero también, estás testing en las últimas versiones de los navegadores, y sabes, Chrome se lanza cada mes también, ¿verdad? Así que tus navegadores se están lanzando cada mes. Así que al actualizar a PlayWrite, también estás testing contra los últimos navegadores, y eso es realmente, realmente importante. Así que asegúrate de mantener PlayWrite actualizado, npm install dash d at playwrite slash test at latest.

Usa localizadores. Así que los localizadores vienen con la ponderación automática y la capacidad de reintentar. Y te animamos encarecidamente a que priorices los atributos orientados al usuario. Así que verás algo como esta página, obtener por rol, ¿qué rol estoy buscando?, estoy buscando el rol de un botón, y ¿cuál es el nombre de ese rol accesible? es submit. Y ese es mi atributo orientado al usuario. También estoy testing que este botón tiene un buen nombre accesible. Así que sabes, esto es realmente bueno, porque estoy testing accessibility. Además estoy escribiendo mi prueba y asegurándome de que mi código es bueno. Así que te animo encarecidamente a que uses nuestros localizadores de Playwright y atributos orientados al usuario.

Usa las afirmaciones de Playwright. Así que hablamos de esto antes, son de reintentos automáticos. Así que asegúrate de que las estás utilizando. Un ejemplo es un peso, asegúrate de que tienes el peso, y luego esperas, y esperas la página aquí, estamos haciendo un get by test ID. Y tenemos el estado, y esperamos que tenga el texto enviado. Así que esa es una afirmación de Playwright para tener texto. Y verás una lista completa de esas en los documentos para tener recuento, para tener texto, para ser visible, etc.

Evita testing las dependencias de terceros.

Entonces, si vas a una API, ¿verdad?, y tal vez no posees esa API, bueno, no necesitas probar esa API, como GitHub, por ejemplo, quiero que mi sitio enlace a GitHub. Bueno, no necesito probar eso. Así que solo necesito probar que el botón es clickeable y que irá allí. Pero luego puedo interceptar esa ruta, y simplemente llenarla con otros data. Y entonces sé que la ruta está funcionando, el enlace está funcionando, pero en realidad no estoy golpeando la API cada vez.

Utiliza Code Gen. En serio, algunas personas se mantienen alejadas de las herramientas que son como, oh, está haciendo todo este trabajo por mí, y no sé qué está haciendo, o es aterrador, me gusta escribir todo yo mismo. Quiero decir, totalmente genial si quieres hacer todo ese trabajo duro tú mismo, está bien. Pero las herramientas realmente te facilitan la vida. Así que te animamos encarecidamente a que las uses.

Permíteme darte una rápida demostración de cómo funciona. Así que estoy en VS code. Solo voy a grabar nuevo y verás que ha creado un archivo de prueba uno para mí. Ahora me da una ventana del navegador y puedo ir a probar este sitio web de Contoso Traders. Así que abre el navegador para mí en este sitio web, y puedes ver aquí en la prueba, tengo una página de espera, ve al sitio web cloudtesting.contostotraders.com. Muy genial. Ahora hagamos algo. Vamos a buscar un Xbox. Este es un flujo de usuario. Lo que el usuario haría, buscarían el producto, lo escribirían, presionarían enter, y luego buscarían. ¿Cuál quieren? Voy a seleccionar el del medio porque se ve genial. Y vamos a añadir dos porque jugar solo no es divertido. Y luego lo añadimos a la bolsa. Ahora en mi bolsa, puedes ver que se añadió uno, así que puedo entrar allí. Puedo ver que el producto está allí. Hay dos allí, y básicamente eso es, ya sabes, realmente caro. Vamos a quitarlo. He cambiado de opinión. No quiero comprarlo. Mi carrito está vacío y mi flujo ha terminado.

Perfecto. Ahora mira mi prueba. Todo esto ha sido generado para mí. Esto es realmente genial porque no tuve que hacer todo ese trabajo para ponerlo en marcha. En cuestión de un minuto, tengo mi prueba escrita. Literalmente puedo presionar cancelar, y luego podría ejecutar esa prueba y ver que realmente funciona. Solo, ya sabes, asegúrate, no sé, algo no salió mal.

Entonces, si ejecuto esa prueba, sí, funciona. Por supuesto que funciona. Aquí está mi rastro. Puedo ver el flujo de usuario real. Puedo revisar y ver si me perdí de algo. Y realmente ahora lo que quiero hacer es comenzar a agregar mis afirmaciones, ¿verdad? Entonces quiero decir, está bien, al final, voy a decir que espero que el Localizador sea visible, ¿verdad? Ahora voy a ejecutar esta prueba. ¿Qué va a pasar? Va a fallar, lo cual es obvio porque presiono el botón de eliminar. No quiero ver esto en mi carrito, pero me gusta ver que mis pruebas fallan antes de que pasen. Entonces sabes, entonces estoy realmente seguro de que está funcionando. Así que estoy moviendo eso ahora antes de que lo eliminen. Está en el carrito. Luego presiono el botón de eliminar. Lo que puedo hacer es que puedo poner eso de nuevo aquí. Pero en lugar de decir que sea visible, puedo decir, quiero que no sea visible. Entonces, una vez que presione eliminar, asegúrate de que el Xbox no sea visible en la página. Y si ejecuto esa prueba, ahora pasará. Tengo mis dos afirmaciones y mi prueba se realiza en cuestión de segundos, y estoy feliz y listo para irme a casa. Así que eso es realmente, realmente genial.

Entonces sí, utiliza Code Jam. Es increíble. Y también utiliza el modo UI. Echemos un vistazo al modo UI. Es mi herramienta favorita.

Entonces, hablamos de esto un poco antes. Aquí está, se ha lanzado y puedo presionar play. Una vez que presiono play, va a ejecutar esa prueba para mí. Y me está dando todo lo que necesito, ¿verdad?

Esta es mi otra prueba. Puedo ejecutarla. Puedo ver las acciones. Esta es una prueba muy simple en la que solo estoy haciendo clic en el botón de comenzar, y está yendo a la página de instalación. Y puedes ver el código resaltado allí en la parte inferior. Y puedes ver la línea de tiempo resaltada.

Ejecutemos una prueba mejor. La prueba que acabamos de crear con CodeGen y aquí tenemos nuestra prueba. Entonces puedes ver que puedo pasar por cada una de esas acciones en el modo UI. Puedo ver en qué se está haciendo clic. Puedo ver el código fuente debajo y puedo pasar por cada paso y entender mejor lo que está pasando. Esto es realmente, realmente bueno para la depuración, porque algo va a suceder en un segundo. Vas a ver, así que espera un segundo y verás lo que va a suceder.

¿Verdad? Tengo mi caja de cámara y como que algo ha sucedido, ¿verdad? Ahora puedes ver que tengo un mensaje de error. La prueba se ha agotado, así que en ese espacio de tiempo mientras te estaba hablando, mi prueba se agotó y tengo que averiguar por qué. ¿Qué pasó? Escribimos una prueba hace un minuto. ¿Qué acaba de pasar aquí? ¿El desarrollador cambió el código? Espero que no. Entonces, echemos un vistazo. Bueno, tenemos una pestaña de error aquí y es, bueno, el código fuente primero me dice línea 12 get by label bag dot click. Así que está esperando el get by label de bag. La pestaña de error me dirá esto también. Está esperando get by label bag. Eso es todo. Eso está bien. Sabes, puedo ver que falla, pero ¿qué hago desde aquí? Y puedo pasar por, ya sabes, cada una de las secciones, la llamada. Puedo ver el localizador. El modo estricto es verdadero.

Entonces eso está bien. Eso realmente no me está ayudando aquí. También puedo revisar todas mis solicitudes de red, lo cual es realmente genial en caso de que necesite hacerlo. No tengo mensajes de consola. Eso es bueno. Pero tengo un mensaje de error y necesito corregirlo.

Ahora, ¿qué harías en esta situación? Tienes una prueba fallida. ¿Cómo arreglas tu prueba fallida? ¿Qué haces? Entonces, la mejor manera de hacerlo es tratar de entender el flujo de lo que estaba sucediendo hasta ese punto. ¿Verdad? Teníamos una página, obtenida por el nombre del botón, añadir a la bolsa, y lo hicimos clic. Así que aquí es donde estamos fallando. Hemos añadido a la bolsa, pero luego hicimos clic en la bolsa. Así que podemos ver los pasos, ¿verdad? Podemos ver lo que pasó antes. Podemos ver lo que pasó después. Puedes ver que el pequeño se añadió a la bolsa. Así que nuestro producto fue añadido a la bolsa, pero por alguna razón, no nos está permitiendo hacer clic en él. Ahora, ¿por qué Playwright no puede hacer clic en ese botón? Esto es lo que estamos tratando de averiguar. Y puedes ver en la línea de tiempo aquí, puedo desplazarme por allí y también ver las acciones. Puedo ver de nuevo, sí, que uno fue añadido a la bolsa.

Entonces esto es realmente genial, pero no lo sé. ¿Cómo arreglo esto? Bueno, hay un par de formas en que podemos hacer esto, ¿verdad? Podemos básicamente decir que este es nuestro problema. Vamos a ponerlo en una instantánea del DOM. Saquémoslo de allí. Entendamos el código. Veamos qué pasó. ¿El desarrollador cambió algo? Como es una instantánea del DOM de nuestra prueba, podemos inspeccionarla. Podemos ir al código. Y si miramos esto aquí, podemos decir, oh Dios mío, mira eso. Hay una etiqueta de área de carrito. Algún desarrollador ha ido y ha cambiado esto a carrito. Y también puedes ver esto a través del árbol de accessibility.

Y puedes ver que es botón carrito, etiqueta de área carrito. Entonces este es nuestro problema, ¿verdad? Tenemos en nuestro localizador, bolsa, obtener por etiqueta bolsa. Pero en nuestro código, tenemos carrito, una incompatibilidad muy simple porque parece una bolsa para mí. Entonces, como probador, creo que suena bien. Pero obviamente, el desarrollador pensó que era un carrito.

Ahora, si uso el botón del localizador de selección, incluso más fácil, puedo simplemente pasar el cursor sobre eso y me va a dar el localizador correcto y puedo hacer clic en él. Lo va a poner en esa caja de abajo. Entonces ni siquiera tengo que mirar el DOM. Ni siquiera tengo que mirar el árbol de accessibility. Puedo simplemente usar un localizador de selección y pasar el cursor sobre él. Y también puedo jugar aquí. Puedo escribir, si pongo carrito, si pongo bolsa, no se encuentra nada, ¿verdad? Entonces realmente puede ver lo que está pasando y simplemente jugar completamente con su código aquí con el patio de juegos del localizador. Entonces esta es una gran manera. Así que descubrimos que obtener por etiqueta carrito es el camino a seguir. E incluso puedes experimentar aún más. Tomemos este aquí. Obtén mi rol botón nombre añadir a la bolsa. Eliminemos añadir a la bolsa y simplemente pongamos añadir. Puedes ver que todavía lo encuentra, ¿verdad?, porque tiene añadir. Aunque tiene añadir a una bolsa, no es una coincidencia exacta. Así que ten cuidado con eso. Pero el localizador te va a ayudar. Esta herramienta te va a ayudar a descubrir, oh, añadir a la bolsa. Solo hay uno de uno, etc. Así que ese es mi localizador de selección. Así que volvamos y consigamos el que queremos. Ahora podemos copiar eso en nuestro código. Ahora, antes de copiarlo, hagamos clic en Modo de Observación, porque queremos que esto se vuelva a ejecutar automáticamente. Y hagamos clic en el icono de Archivo, que luego simplemente abrirá nuestro VS Code para nosotros. Vamos a la línea 12.

Pegaremos nuestro localizador, el correcto. Y automáticamente, va a volver a ejecutar esa prueba para nosotros. Y verás aquí, se está volviendo a ejecutar. Va a pasar por esto. Y ahora Playwright puede encontrar ese localizador, porque realmente existe en la página, y días felices. Nuestra prueba pasa. Y puedes ver ahora que está funcionando exactamente como debería hacerlo. Así es como depuraríamos, etc. Modo de interfaz de usuario realmente, realmente genial, así que asegúrate de usar el modo de interfaz de usuario durante toda tu experiencia de desarrollador.

Así que el escalado. Hablamos un poco sobre el escalado. Básicamente, quieres ejecutar en CI. Recomendamos encarecidamente que ejecutes tus pruebas en CI. Y como dije, viene con un flujo de trabajo de GitHub Actions. Así que eso simplemente viene y funciona de inmediato. Así que asegúrate de usar eso. Y luego si quieres fragmentar, puedes también fusionar informes. Así que aquí estoy tomando mi sitio web. Y si vuelvo aquí, la duración de mi prueba fue de 18 minutos, ¿verdad? Y luego, simplemente fragmentando en GitHub, lo reduje a ocho minutos. Así que lo ejecuté en cuatro máquinas. Y luego pude fusionar esos informes para tener un informe, que me da el informe único con mis 292 pruebas. Y una fue omitida. Necesito arreglar eso. 291 pasaron, y estamos hablando de ocho minutos. Eso no está nada mal. Así que eso es fusionar informes.

Así que recuerda, Playwright es de código abierto y gratuito. Es de Microsoft. Y puedes ver que estamos literalmente creciendo continuamente. Nos encantan las estrellas de GitHub.

Asegúrate de darnos una estrella en GitHub. Nos pagan en estrellas. Así que si no nos das una estrella, no nos pagan. Lo sé, solo estoy bromeando. Pero sí, danos una estrella si te gusta lo que estamos haciendo.

Tenemos unos embajadores increíbles que están haciendo un trabajo loco y genial ahí fuera. Así que asegúrate de seguirlos y ver lo que están haciendo. Y síguenos en Discord, donde vas a ver, no solo videos y artículos, sino también una community realmente útil para ayudarte con la ayuda de Playwright. Así que haz cualquier pregunta allí, y la community te respaldará.

Entonces, mi única pregunta es, ¿estás listo para Playwright? Espero que sí. Espero que ahora puedas ver que Playwright es fácil, es divertido. Testing es fácil, es divertido. Y ahora todo depende de ti. Puedo volver aquí el próximo año y dar esta misma charla. Y no vamos a ir a ninguna parte. Tienes que hacer el trabajo.

Así que asegúrate de salir y simplemente comienza a escribir tus pruebas. Y toma un segundo, comienza pequeño, haz una, cinco minutos al día. Incluso cinco minutos a la semana. Oh, Dios mío, puedes imaginar lo que lograrías en un año si solo dedicaras cinco minutos a la semana a escribir una prueba. Muchas gracias a todos. Que tengas un gran día. Adiós.