Todos pueden escribir pruebas fácilmente

Rate this content
Bookmark

Echemos un vistazo a cómo Playwright puede ayudarte a escribir tus pruebas de extremo a extremo con herramientas como Codegen que generan pruebas basadas en la interacción del usuario. Exploraremos el modo UI para una mejor experiencia de desarrollador y luego repasaremos algunos consejos para asegurarnos de que no tengas pruebas inestables. Luego hablemos de cómo poner en marcha tus pruebas en CI, depurar en CI y escalar usando fragmentos.

21 min
11 Dec, 2023

Comments

Sign in or register to post your comment.

AI Generated Video Summary

Playwright es una herramienta de prueba de extremo a extremo confiable para aplicaciones web modernas que proporciona una API, aislamiento total, ejecución rápida y soporte para múltiples idiomas. Ofrece características como auto-ponderación, reintentos de aserciones, pruebas sin problemas de iframes y shadow DOM, aislamiento de pruebas, paralelismo y escalabilidad. Playwright proporciona herramientas como la extensión VS Code, UiMode y Trace Viewer para escribir, depurar y ejecutar pruebas. Las pruebas efectivas priorizan los atributos orientados al usuario, utilizan localizadores y aserciones de Playwright, y evitan probar dependencias de terceros. Playwright simplifica las pruebas generando pruebas, proporcionando generación de código y modo UI, y permite ejecutar y depurar pruebas fácilmente. Ayuda a corregir pruebas fallidas y analizar cambios en el DOM, corregir desajustes de localizadores y escalar pruebas. Playwright es de código abierto, gratuito y está en constante crecimiento.

1. Introducción a Playwright

Short description:

Todos pueden escribir pruebas fácilmente. Playwright es una prueba de extremo a extremo confiable para aplicaciones web modernas en cualquier navegador. Proporciona una API, aislamiento total, ejecución rápida y admite varios idiomas. Hay muchas más razones para usar Playwright, pero por ahora nos centraremos en estas.

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.

2. Características de Playwright

Short description:

Playwright proporciona auto-espera, reintentos de aserciones, pruebas sin interrupciones de iframes y shadow DOM, aislamiento de pruebas, paralelismo y escalabilidad para una ejecución de pruebas más rápida.

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.

3. Herramientas de Playwright y Mejores Prácticas

Short description:

La extensión de VS Code te permite escribir, reproducir y depurar pruebas, abrir el visor de trazas y utilizar herramientas de generación de código y selección de localizadores. UiMode proporciona una interfaz visual para ejecutar y controlar pruebas, mientras que Trace Viewer ayuda con la depuración en CI. Playwright también ofrece GitHub Actions para una fácil integración con CI. Es importante priorizar las pruebas de extremo a extremo en tu estrategia de pruebas.

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.

4. Escribir Pruebas Efectivas

Short description:

Las pruebas de extremo a extremo son más rápidas y económicas, reduciendo la necesidad de muchas pruebas unitarias. Prioriza los atributos orientados al usuario y la accesibilidad utilizando los localizadores de Playwright. Utiliza las afirmaciones de Playwright para pruebas de reintentos automáticos. Evita probar dependencias de terceros.

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.

5. Pruebas de APIs y Generación de Código

Short description:

Si estás utilizando una API que no posees, no necesitas probarla. Solo asegúrate de que el botón sea clickeable y el enlace funcione. Utiliza Code Gen para simplificar tu trabajo. Permíteme darte una rápida demostración en VS code, probando el sitio web de Contoso Traders. Busca un Xbox, selecciona uno, añádelo a la bolsa y luego retíralo. Tu flujo está hecho.

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.

6. Generación y Ejecución de Pruebas

Short description:

Puedo generar pruebas de manera rápida y fácil. Agregar afirmaciones ayuda a asegurar que las pruebas estén funcionando correctamente. Utiliza Code Jam y el modo UI para una mejor experiencia de prueba.

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.

7. Ejecución y Depuración de Pruebas

Short description:

Una vez que se lanza la prueba, se puede ejecutar presionando play. El modo UI permite una fácil depuración y comprensión de cada paso. Sin embargo, puede haber casos en los que la prueba se agote y se muestre un mensaje de error. En tales casos, la pestaña de error proporciona información sobre la línea específica de código que está causando el problema.

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.

8. Arreglando una Prueba Fallida y Analizando Cambios en el DOM

Short description:

Puedo revisar mis solicitudes de red, buscar mensajes de consola y corregir el mensaje de error. Para arreglar una prueba fallida, comprende el flujo de acciones. En este caso, el producto se añadió a la bolsa pero no se puede hacer clic en él. Usa la línea de tiempo para analizar las acciones. Coloca el problema en una instantánea del DOM para inspeccionar y entender el código. Verifica los cambios realizados por los desarrolladores, como el cambio de la etiqueta de área a carrito.

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.

9. Arreglando la Incompatibilidad del Localizador y Usando el Localizador de Selección

Short description:

Tenemos una incompatibilidad en nuestro localizador y código. Al usar el localizador de selección, podemos encontrar fácilmente el localizador correcto y hacer clic en él sin mirar el DOM o el árbol de accesibilidad. El patio de juegos del localizador nos permite experimentar y entender completamente nuestro código. Descubrimos que 'obtener por etiqueta carrito' es el camino a seguir. El localizador nos ayuda a encontrar elementos incluso con coincidencias parciales. Copiemos esto en nuestro código y activemos el Modo de Observación para reejecuciones automáticas. Abramos VS Code y vayamos a la línea 12.

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.

10. Depuración, Escalado y Código Abierto

Short description:

Pegaremos nuestro localizador, el correcto. Playwright puede encontrar ese localizador, porque realmente existe en la página, y días felices. Nuestra prueba pasa. Así es como depuraríamos. Quieres ejecutar en CI. Viene con un flujo de trabajo de GitHub Actions. Si quieres fragmentar, también puedes fusionar informes. Playwright es de código abierto y gratuito, de Microsoft. Estamos literalmente creciendo continuamente.

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.

11. Conclusión y Acción

Short description:

Asegúrate de darnos una estrella en GitHub y síguenos en Discord. Playwright es fácil y divertido, pero depende de ti hacer el trabajo. Comienza pequeño, dedica unos minutos al día o a la semana para escribir pruebas, e imagina lo que puedes lograr en un año. ¡Gracias y que tengas un gran día!

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.

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

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2022TestJS Summit 2022
20 min
Testing Web Applications with Playwright
Testing is hard, testing takes time to learn and to write, and time is money. As developers we want to test. We know we should but we don't have time. So how can we get more developers to do testing? We can create better tools.Let me introduce you to Playwright - Reliable end-to-end cross browser testing for modern web apps, by Microsoft and fully open source. Playwright's codegen generates tests for you in JavaScript, TypeScript, Dot Net, Java or Python. Now you really have no excuses. It's time to play your tests wright.

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.