En la Cima de la Pirámide: Pruebas de Playwright a Escala

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Descubre cómo abordamos los desafíos comunes de una gran suite de pruebas E2E y facilitamos la refactorización de nuestro código base de React.

En el último año, pasamos de cero a 20,000 líneas de pruebas de Playwright, llevando sus capacidades más allá de las pruebas básicas de extremo a extremo. Esta charla explorará los desafíos que encontramos al escalar nuestra configuración de Playwright y cómo los resolvimos, gracias al ecosistema robusto y la creatividad del equipo.

La charla cubre:

- Enfoques de prueba y dónde encajan las herramientas comunes en la pirámide de pruebas

- Desafíos al escalar suites de pruebas E2E: rendimiento, inestabilidad, propiedad, simulación y más

- Cómo resolvimos estos desafíos para desbloquear la refactorización de un gran código base de React

- Consejos y trucos avanzados de Playwright

This talk has been presented at React Summit 2025, check out the latest edition of this React Conference.

Kate Marshalkina
Kate Marshalkina
25 min
13 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Introducción a Playwright como una herramienta de prueba de extremo a extremo con fácil instalación y generación de código. Las características incluyen comparaciones visuales, pruebas de API y una experiencia de desarrollador de primera clase. Playwright ofrece capacidades de IA, herramientas de prueba prácticas y estrategias de prueba innovadoras. Se abordan desafíos en pruebas de dominios especializados, junto con las mejores prácticas para dependencias de prueba y legibilidad. Optimización de la eficiencia de las pruebas a través del paralelismo, la organización del código y el uso de caché de red. La discusión también cubre la mejora del rendimiento de las pruebas, la gestión de trabajadores, la optimización de dependencias, la estabilidad de las funciones de prueba y el uso de Playwright sharding en ejecuciones de CI/CD.

1. Explorando la Herramienta de Pruebas Playwright

Short description:

Introducción a Playwright como una herramienta de pruebas end-to-end con fácil instalación y generación de código. Las características incluyen comparaciones visuales, pruebas de API y una experiencia de desarrollador de primera clase con depuración y Trace Viewer.

Hemos codificado rápidamente nuestra aplicación, o heredamos una gran base de código heredada. ¿Cómo la probamos? ¿Es fácil probar en 2025? Esa es una pregunta complicada. Y antes de que me adentre, una verificación rápida. ¿Podría levantar la mano si ha trabajado con Playwright antes? Genial. Es como casi la mitad de la audiencia, tal vez incluso más.

Para el resto de nosotros, una breve introducción a Playwright. Playwright es una herramienta de pruebas end-to-end muy popular. Es muy fácil de instalar. Con solo un comando, obtienes los navegadores predeterminados, configuración, prueba de ejemplo, y incluso GitHub Action. Viene con Code Jam. Te permite generar pruebas sin escribir ningún código en absoluto. Básicamente haces clic en tu navegador, en tu sitio web, y obtienes de vuelta un código de prueba simple, básico, pero funcional.

Cuando tienes escenarios de prueba más avanzados, Playwright tiene todas las características. Comparaciones visuales, instantáneas, pruebas de API, pruebas de extensiones de Chrome, pruebas de componentes. Si por alguna razón no te gusta TypeScript, hay otras opciones también. Cuando las pruebas inevitablemente fallan, Playwright ofrece una experiencia de desarrollador de primera clase. Tiene un depurador integrado, extensión de VS Code, capturas de pantalla, informes, videos, y mi favorito, el Trace Viewer.

2. Características de AI de Playwright y Herramientas de Pruebas Prácticas

Short description:

Descripción general de las características de Playwright, incluyendo Trace Viewer para fallos de prueba, capacidades de AI como AI prompt y Playwright MCP server, y herramientas de prueba prácticas con auto-weighting, assertions y soporte comunitario.

El Trace Viewer es una solución integral para cualquier fallo de prueba. Proporciona todos los pasos de la prueba junto con capturas de pantalla, errores, registros de consola, solicitudes de red y básicamente todo lo que usualmente verificamos en las herramientas de desarrollo del navegador. Por supuesto, la diapositiva obligatoria de AI. Playwright tiene un par de características interesantes de AI, copiar error como AI prompt y Playwright MCP server para permitir que los modelos de lenguaje grande se comuniquen con las APIs de Playwright. Permítanme darles una demostración rápida. Aquí, estoy pidiendo a Courser que escriba un borrador rápido de revisión de conferencia para mi blog. Courser pide a Playwright MCP que obtenga una agenda de conferencia, y Playwright devuelve una instantánea de accesibilidad de la página, algo que es muy fácil de digerir para Courser.

Y como resultado, Courser genera un buen primer borrador, incluso para las charlas que aún no se han presentado. Bastante genial, pero por supuesto, el objetivo principal de Playwright es ayudarnos a escribir pruebas confiables y predecibles y Playwright es una herramienta muy práctica. Viene con auto-weighting y web-first assertions. La autenticación y multiusuario vienen de serie, lo mismo con el paralelismo y sharding. Finalmente, tiene una gran comunidad que proporciona plugins comunitarios, mejores prácticas e integraciones con otras herramientas. En resumen, Playwright cumple con todos los requisitos para facilitar las pruebas.

3. Challenges in Testing Specialized Domains

Short description:

Unirse a un equipo de análisis de salud enfrentando desafíos en pruebas, lidiando con dominios especializados, sistemas heredados y componentes de UI complejos.

Al menos eso es lo que pensé cuando hace un año, me uní a un equipo en ATO, una empresa de análisis de salud que ofrece una gama de productos para científicos de datos en el sector de la salud. Es un dominio de negocio altamente especializado y regulado que probablemente tiene un acrónimo para casi todo en el mundo. Déjame darte un ejemplo. En la Clasificación Internacional de Enfermedades, eso es algo real, hay un código, W6162XD, que significa, literalmente significa, golpeado por un pato, encuentro subsiguiente. Y en tal dominio de negocio especializado, se pidió a nuestro equipo que cubriera todas las características principales con pruebas automatizadas para propósitos de regulación.

El alcance incluía 64 épicas de pruebas. Todavía recuerdo este número. Para un no profesional como yo, la UI parecía un millón de casillas de verificación, acrónimos, tablas con números aleatorios por todas partes, impulsado por una aplicación de React de cinco años y un backend de Java de diez años. Java tenía su propia historia pasando de monolito a microservicios, luego de vuelta, dejándonos con un montón de APIs heredadas y desactualizadas, pero eso es para otro momento. Por ahora, centrémonos en React. A medida que el producto evolucionaba, algunos de los componentes han crecido a más de mil líneas de código con esos enormes use effects, con dependencias faltantes, y array de dependencias, y todo eso.

React versión 17, la mayor parte del código sin tipar. ESLint y Prettier se perdieron durante la migración a la nube. Y antes de continuar, solo quería mencionar que esta no es una situación poco común para empresas en crecimiento que se centran en construir nuevas características. Ahora, dicho esto, nuestra primera reacción a este proyecto se puede resumir con una cita de mi compañero de equipo. Este código es imposible de probar. O, hablando en lenguaje científico, R45.4, irritabilidad y enojo. El desafío no fue aceptado. Con todas esas excusas corriendo en mi cabeza, no, no es mi trabajo, incluso un desarrollador junior puede hacer eso, incluso AI puede hacer eso, y después de cinco horas de estar preguntando a chatgpt, estúpida AI, nunca tomará mi trabajo, está bien, escribiré la prueba, al menos dime qué tipo de prueba debo escribir, ¿por dónde empiezo? Necesitábamos una estrategia de pruebas.

4. Innovative Testing Mushroom Strategy

Short description:

Introducción a varias estrategias de prueba como la pirámide de pruebas, diamante, trofeo y Dorito que llevan a la innovadora estrategia de prueba de hongo para pruebas end-to-end.

Ahora es el momento para un breve bloque teórico. Probablemente la estrategia de prueba más popular es la pirámide de pruebas. Promueve dividir el software en unidades más pequeñas y comprobables. No es nuestro caso, para ser honestos.

La otra opción es poner la pirámide al revés para obtener la pirámide de pruebas inversa. Si ponemos un poco de helado encima, entonces obtenemos el cono de helado de pruebas, la estrategia de prueba predeterminada para muchas empresas. No es tan sabroso. La mayoría de las pruebas son manuales, y solo algunas de ellas se automatizan.

Otra opción es el diamante de pruebas, que pone el enfoque principal en las pruebas de integración. Otra evolución del diamante de pruebas que es más popular en la comunidad de front-end es el trofeo de pruebas de Kent C. Dots. Aclara lo que significan los diferentes tipos de pruebas en el contexto del ecosistema moderno de JavaScript y también hace que las verificaciones estáticas como slint y TypeScript sean más explícitas.

No todos saben, pero la estrategia favorita de Kent es el Dorito de pruebas de Tim Meyers. Déjame leértelo de arriba a abajo. Pruebas que planeo escribir. Pruebas que empiezo a escribir. Pruebas que elimino porque pienso que son estúpidas, y pueden tomar mucho tiempo y no valen la pena. Finalmente, ¡pruebas! Y el Dorito de pruebas es un buen recordatorio de que la teoría y la práctica no siempre tienen una coincidencia perfecta.

Así que, sin más preámbulos, por favor den la bienvenida a la nueva estrategia de pruebas, el hongo de pruebas. La copa del hongo se trata de pruebas end-to-end. Cumple con los requisitos de regulación y también nos ayuda a construir una red de seguridad para que podamos comenzar a refactorizar e introducir pruebas de integración y unitarias. El hongo de pruebas es un organismo vivo, por lo que se espera que cambie su forma una vez que aprendamos más.

Genial, tenemos nuestra estrategia, así que es hora de ejecutar. Todo el equipo se sentó a escribir tantas pruebas como fuera posible, lo más rápido posible. Y un mes después... Fue un desastre. No funcionó. Cuantas más pruebas escribíamos, más fallaban, por todas las razones aleatorias y era imposible averiguar qué estaba pasando. Era el momento para una acción de emergencia. A saber, documentación escrita.

5. Best Practices and Test Dependencies

Short description:

Tratando con las mejores prácticas y desafíos en el uso de la API de Playwright, incluyendo el manejo de dependencias de prueba y asegurando procedimientos de prueba correctos.

Al menos la parte de las mejores prácticas. Aparentemente, estábamos usando mal la API de Playwright. Y aquí tengo un par de ejemplos para ti. La línea en la parte superior es la forma incorrecta de verificar el texto de bienvenida en pantalla. Y la línea de abajo es la forma correcta de hacerlo. Ambas funcionan, solo que la primera a veces falla aleatoriamente. Y para ser honesto, la diferencia es sutil. Especialmente cuando revisas miles de líneas de código de prueba.

Afortunadamente, hay una solución simple. Instalamos el plugin ESLint Playwright. Solucionó todos los problemas y también nos ayudó a aprender cuál era la forma correcta de usar Playwright. Genial, con eso, continuamos. Y dos meses después de iniciado el proyecto, nos dimos cuenta de que estábamos atrasados. Así que tuvimos que pedir ayuda a nuestros colegas de otros equipos. Fue entonces cuando enfrentamos nuestro siguiente desafío.

Dependencias de prueba. Como recuerdas, estamos lidiando con un dominio de negocio bastante complejo. Un recorrido típico del usuario puede tomar varios minutos antes de que logres algún resultado significativo. Y para un desarrollador, es tentador reutilizar resultados de pruebas anteriores para construir nuevas pruebas sobre eso. Desafortunadamente, rompe completamente los reintentos de prueba y hace que la depuración local sea prácticamente imposible. Nunca sabes en qué orden y qué pruebas ejecutar para reproducir el problema.

6. Isolating Tests and Enhancing Readability

Short description:

Siguiendo las mejores prácticas al aislar pruebas, ejecutarlas en paralelo y mejorar la legibilidad de las pruebas usando Allure Reports en Playwright.

Ahora, una vez más, decidimos seguir las mejores prácticas. Y una de ellas dice, haz que las pruebas sean lo más aisladas posible. Bueno, fácil de decir, tuvimos que imponerlo con el modo completamente paralelo e incrementar el número de workers a tres para realmente ejecutar las pruebas en paralelo. Eso reveló algunos problemas que resolvimos. Y con eso, finalmente, estuvimos de acuerdo. Nuestras pruebas se volvieron mucho más estables y comenzaron a detectar errores reales, como ese en la esquina superior derecha.

Vamos a ver qué está mal con eso. Bien, esa es mi prueba. Puedo ver inmediatamente cuál es el problema. Es una de las APIs de backend que no está devolviendo la respuesta correcta. Así que lo estoy enviando al equipo de backend. El equipo de backend lo abre, aparentemente en el modo oscuro, y no puede entender nada, al igual que probablemente tú, porque es demasiado pequeño. Así que nos lo devuelven, y nosotros se lo devolvemos a ellos, y así sucesivamente.

Z63.1, problemas en la relación con los suegros. Aparentemente, nuestros informes de prueba no eran legibles en absoluto, y tuvimos que mejorarlo. Cuando se trata de hacer el código más legible, ya sabemos cómo hacerlo.

7. Optimizing Testing Efficiency

Short description:

Organizando el código usando el modelo de objeto de página, integrando StepDecorator para pasos lógicos, y acelerando la velocidad de las pruebas para pipelines de despliegue eficientes.

En las pruebas, hay un patrón común, el modelo de objeto de página, donde organizas tu código en pantallas o páginas. Por ejemplo, aquí tengo una clase de página de inicio de sesión, y contiene todas las acciones que puedes realizar en esa pantalla o página. Inicio de sesión, cierre de sesión, restablecimiento de contraseña, etcétera. Ya teníamos nuestro código organizado de esta manera. Y aparentemente, estábamos a solo un paso de hacer que nuestros informes fueran igual de legibles.

Y cuando digo un paso, lo digo literalmente con StepDecorator. StepDecorator agrupa acciones de Playwright de bajo nivel en pasos de nivel superior, pasos lógicos que puedes entender. No viene listo para usar, pero hay documentación sobre cómo puedes configurarlo para tus necesidades. Con eso, nuestros informes de prueba se volvieron mucho más legibles, incluso para nuestro encantador equipo de backend.

Si hago un poco de zoom hacia afuera, así es como se ve la prueba fallida en el informe de pruebas. Contiene todos los pasos de la prueba, capturas de pantalla, videos, reintentos de prueba, etiquetas, historial, y todo lo que viene de Allure Reports. Allure Reports es una herramienta de código abierto, multiplataforma y multiframework para construir hermosos informes de prueba para que incluso los usuarios no técnicos puedan entender qué está pasando en la prueba. Y como de costumbre, es muy fácil configurarlo con Playwright. Genial, con eso, estamos en la recta final cuando nuestro equipo de ingeniería de plataforma se acercó con un problema mucho más grande. Sí, nuestras pruebas estaban en verde.

8. Efficient Test Speed Optimization

Short description:

Optimizando la velocidad de las pruebas ejecutando en modo paralelo, utilizando el plugin de caché de red de Playwright para una ejecución de pruebas eficiente.

Sí, eran estables, pero eran súper lentas. Podían bloquear el pipeline de despliegue durante una o dos horas, y no era aceptable. Para ser honesto, nunca nos enfocamos en la velocidad. Teníamos otras prioridades. Así que, como recordatorio, estamos ejecutando pruebas en modo completamente paralelo y trabajadores libres. Y con solo un cambio de configuración, pasamos de 51 minutos a 17 minutos. Sí, simplemente aumentamos el número de trabajadores.

Podemos ver el espacio en blanco al principio. Todavía tenemos margen de mejora, pero ya es un buen primer paso. Por supuesto, no hace que cada prueba individual se ejecute más rápido. Simplemente ejecutamos más de ellas en paralelo. Si comparamos las pruebas de extremo a extremo con las pruebas de integración, las pruebas de integración generalmente se ejecutan más rápido porque omiten o simulan operaciones costosas.

9. Enhancing Test Performance with Playwright

Short description:

Evitando mocks para mejorar el rendimiento utilizando el plugin de caché de red de Playwright.

En Playwright, tenemos una API de red para interceptar solicitudes HTTP. Pero personalmente, no soy un gran fan de este enfoque. En un proyecto, simulamos todas las solicitudes HTTP. Nuestras pruebas eran súper rápidas, súper verdes, pero nunca detectaron un solo error. En cambio, estábamos constantemente regenerando y actualizando los mocks. No es súper genial. ¿Podríamos obtener una mejora de rendimiento similar, pero sin mantener realmente los mocks? Trabajando sin mocks, como lo llamo.

Esto es exactamente lo que ofrece el plugin de caché de red de Playwright. Déjame mostrarte un ejemplo. Imagina que tenemos cinco pruebas lentas. Cada una comienza realizando alguna operación lenta, digamos abriendo un proyecto de prueba. Con el caché de red de Playwright, la primera prueba realizará la operación, no importa si obtienes o envías múltiples solicitudes, o solo una, y almacenará el resultado en caché. Todas las demás pruebas reutilizarán ese caché como mocks. En nuestro caso, en realidad teníamos 200 pruebas así y recuperamos 10 minutos de tiempo de ejecución de pruebas. Eso es una locura.

Ahora, si piensas que es hacer trampa, no estás equivocado, porque ya no es una prueba pura de extremo a extremo. Es por eso que en el hongo de pruebas, nuestras pruebas de integración se sitúan dentro de la copa del hongo. Y podría hablar más y más sobre el hongo de pruebas, porque es muy divertido, pero honestamente, lo inventé completamente para los propósitos de esta charla, para ilustrar el enfoque que tomamos para este proyecto en particular. Y tu enfoque será diferente. Espero que el hongo de pruebas te inspire a explorar las diferentes formas y estrategias que existen y encuentres lo que funciona para ti y hace que las pruebas, si no más fáciles, al menos más divertidas.

QnA

Testing Evolution and Code Enhancement

Short description:

Reflexionando sobre la estabilidad de las pruebas, las actualizaciones de código y el desarrollo mejorado a través de estrategias de prueba.

Con eso, permíteme recapitular. Escribimos todas las pruebas. Misión cumplida. Son estables y legibles. Detectan errores reales. Se ejecutan en modo paralelo completo. Gran trabajo del equipo.

Pero hay algo más que no mencioné, un efecto secundario inesperado. Hoy, un año después, tenemos React y otras bibliotecas principales actualizadas. Duplicamos esas pruebas de integración obsoletas con esos mocks heredados que nadie podía mantener. El equipo cambió a Monorepo para mejorar la experiencia del desarrollador.

Migramos a una estructura de código de diseño por características para alinearnos mejor con nuestro dominio de negocio y también para comenzar a descomponer nuestro código en unidades más pequeñas y comprobables. Aceleró la migración a TypeScript. Hoy, construir nuevas características es mucho más fácil. Es una base de código completamente diferente, pero sé que todo comenzó con las pruebas. Así que volviendo a la pregunta, ¿es fácil probar? Depende de la estrategia correcta, la disciplina y la habilidad. Pero la buena noticia es que todo lo demás se vuelve más fácil cuando tienes tus pruebas bien hechas.

Testing Approaches and Parallelism

Short description:

Kate en React Summit 2025 discutiendo enfoques de prueba y paralelismo, incluyendo ideas sobre deshabilitar la paralelización para suites de prueba específicas y el uso de workers en CI.

Aquí está mi favorito. RS 202.5, Obsessed with Testing, en React Summit 2025. Mi nombre es Kate. Estoy colaborando en redes sociales. Felices pruebas. Gracias.

Tenemos Slido funcionando. Y no olvides que puedes agregar tus preguntas mientras discutimos. Y sí, vamos a ver quién vota qué.

Pero, ¿por qué no comenzamos con los enfoques de prueba? Así que pasaste por varios snacks diferentes que representan enfoques de prueba. ¿Cuál crees que es el mejor? Creo que esa es una pregunta con asterisco. Sí, esa es complicada porque el punto de mi charla es que depende de la base de código que manejes. Y a veces, como mi mejor opción es, por supuesto, la clásica pirámide de pruebas, pero no siempre es posible comenzar con ella si lidias con una base de código heredada o, ya sabes, la situación es la que es.

Así que diría que encuentres lo que funciona para ti y luego mires alrededor porque hay algunas personas inteligentes que proponen ideas interesantes. Absolutamente. Pero creo que todos podemos estar de acuerdo en cuál es la estrategia de prueba más linda, que es obviamente el Dorito. No sé sobre el Dorito. Tal vez. Depende del sabor.

OK, veamos. ¿Qué tal el paralelismo? Tenemos un par de preguntas sobre eso. Entonces, ¿hay una manera de deshabilitar la paralelización para ciertos conjuntos de pruebas que tienen largos tiempos de carga inicial? Sí, creo que lo que la persona quiere lograr es perfectamente posible. Playwright es una herramienta muy configurable, pero yo cambiaría eso. Cambia eso. Así que nos forzamos en esta situación donde tuvimos que lidiar con el modo paralelo completo y nos ayudó mucho a seguir las mejores prácticas y nos ayudó a mantenerlo a medida que crece. Increíble. Increíble. Y sobre ese mismo tema, entonces en los trabajadores paralelos, ¿cuántos usaron finalmente? O quizás la pregunta más amplia es, ¿cómo determinas cuántos usar? ¿Y estaban ejecutándose en CI? ¿En integración continua? Sí. Actualmente usamos 12 trabajadores en CI. No lo usamos en local, por ejemplo.

Managing Workers and Flaky Tests

Short description:

Discusión sobre el uso de workers en CI y localmente, gestión de pruebas end-to-end inestables siguiendo las mejores prácticas de Playwright, y diferenciación entre at step y test.step para la optimización de pruebas.

Local, uso un máximo de cuatro workers. En nuestro caso, simplemente elegimos la máquina más grande que estaba disponible para nosotros en CI y eso es todo. Fue simple. El número de CPUs. Sí. Trabaja con lo que tienes, ¿verdad? Increíble.

Y entonces, ¿qué hay de esas pruebas end-to-end que son – cómo te aseguras de que no sean inestables? Porque tienes algún problema con el servidor, algún tiempo de inactividad aleatorio, algo más sale mal. ¿Qué haces contra las pruebas end-to-end inestables? Esa es una gran pregunta. Entonces, si sigues las mejores prácticas de Playwright, reduces la inestabilidad innecesaria que proviene del hecho de que estás usando el navegador y hay algunas latencias, etcétera. Ahora, si tu servidor está caído, no hay nada que pueda ayudarte. Y eso está en el núcleo de la prueba end-to-end en lugar de solo todo el conjunto.

Así que dejamos que fallen si el servidor falla y avisamos a nuestro encantador equipo de backend para que lo arregle. Ahora hay estos enfoques mixtos, como mencioné, con estas mismas pruebas de integración cuando simulas algunas de estas cosas. Este es el otro enfoque que puedes usar. Y puedes ser creativo. Sí. Sí. Bien. De nuevo, tienes que adaptarte a las circunstancias, ¿verdad? Tienes que ser creativo para cualquier problema que tengas a mano. Bien. Tenemos una pregunta sobre, una pregunta muy específica. ¿Cuál es la diferencia entre at step y test.step? Es lo mismo. Es solo que at step es un decorador que envuelve los métodos por ti. Hermoso. Así que no necesitas modificar toda tu base de código o las pruebas existentes, solo agregas el decorador. Sí. Así que eso es una cuestión de rendimiento. De nuevo, ¿qué prefiere tu equipo? ¿Cuál es tu estilo? ¿Estás acostumbrado a trabajar con decoradores? ¿No lo estás? Genial.

Optimizing User Registration Dependencies

Short description:

Discusión sobre la gestión de dependencias de registro de usuario utilizando usuarios de prueba preconfigurados para evitar registros repetitivos.

Entonces, veamos. Están llegando muchas preguntas nuevas y geniales. Me encanta ver esto. Aunque estamos teniendo un poco de discoteca silenciosa y por lo tanto está muy tranquilo en la vida real aquí, todos estamos teniendo una interacción virtual increíble, lo que me lleva de vuelta a como hace cinco años. ¿Alguien? ¿Vibras de 2020? Bien.

Entonces, de acuerdo. ¿Qué tal, cómo abordas, por ejemplo, las dependencias en el registro de usuarios sin repetir los registros cada vez? Sí. Esa es una gran pregunta. En primer lugar, tenemos usuarios de prueba preconfigurados como datos de ejemplo que tenemos y ya contienen algunos usuarios de prueba. Así que probamos el registro solo una vez, pero luego usamos esos usuarios preconfigurados.

Genial. Así que a medida que llegan las preguntas, no olviden que pueden votar las que quieren escuchar respondidas. Pero si su pregunta no es respondida, o si quizás estaban demasiado absortos por las alegrías de pensar en estrategias de prueba para hacerla aquí en línea en Slido, aquellos de ustedes que están en persona tendrán la oportunidad de unirse al rincón de preguntas y respuestas de Kate más tarde.

Optimizing Test Functions and Stability

Short description:

Discusión sobre el uso de fixtures para código repetido en pruebas de Playwright y la importancia de la estabilidad en las funciones de prueba.

Muy bien. Pero mientras tanto, de vuelta a nuestra discoteca virtual, fiesta de discoteca silenciosa. Ojalá tuviéramos patines o algo así. ¿No? ¿Solo yo? Estoy seguro de que nadie se lastimaría. Eso estaría bien.

De acuerdo. Entonces, hablando de inicios de sesión, supongo, y registro, ¿alguna idea sobre cómo optimizar generadores de inicio de sesión o funciones utilitarias que se ejecutarán para cada prueba? Esta persona ha tenido problemas con, o su equipo ha tenido problemas con la paralelización y los tiempos de espera al alcanzar varios puntos finales. De acuerdo. La respuesta es bastante larga, así que hablemos después de la charla. En resumen, para el código repetido, usamos mucho fixtures.

Significan algo diferente en Playwright que en otras cosas. Y para la estabilidad, necesitamos hablar, porque depende. Depende. Depende. La espada más utilizada del ingeniero de software. Absolutamente. De acuerdo. Creo que tenemos tiempo para un par de preguntas más, si te apetece. Estoy listo para una charla, honestamente. Vamos a rockear. Habrá más charlas en el escenario alternativo, así que sí. Pero no te preocupes, si te pierdes alguna de las charlas, porque estás, de nuevo, pasando un gran momento hablando silenciosamente sobre pruebas aquí arriba, no te preocupes.

Playwright Sharding in CI/CD Runs

Short description:

Discusión sobre la utilización de playwright sharding en ejecuciones de CI/CD y las consideraciones en torno a su implementación.

They'll record it. You can catch them later. So we will make sure to catch that. Once you've had a chance to cool down as well. But let's see, would you be willing to do one more for our audience here? Can we get a virtual woo to encourage this? Absolutely. Amazing. Fabulous.

All right. Let's see. Our most popular question at the end is, are you using Playwright sharding in CI and CD runs? And if not, why not? We just don't need it. We use a large machine. As soon as we need it, we will use it. Sharding requires a bit of massaging of the reports, so you need to merge them back. And we don't want to do that.

When we grow big enough, we will do that for sure. So again, depending on the need, right? Depending on what your actual capacity is and what your actual needs are. But it's a great question. Awesome. Awesome. Well, I love that we have such a colorful discussion going on about what I'm now going to think of as a very hunger-inducing part of software development, testing strategy. So can we all please give a virtual and real huge, huge thank you to the amazing Kate and all of the testing shapes. Thank you very much. Thank you so much, Kate.

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

Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Desarrollo Efectivo de Pruebas
TestJS Summit 2021TestJS Summit 2021
31 min
Desarrollo Efectivo de Pruebas
Top Content
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
Playwright Test Runner
TestJS Summit 2021TestJS Summit 2021
25 min
Playwright Test Runner
Top Content
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.
Todos pueden escribir pruebas fácilmente
TestJS Summit 2023TestJS Summit 2023
21 min
Todos pueden escribir pruebas fácilmente
Playwright is a reliable end-to-end testing tool for modern web apps that provides one API, full isolation, fast execution, and supports multiple languages. It offers features like auto-weighting, retrying assertions, seamless testing of iframes and shadow DOM, test isolation, parallelism, and scalability. Playwright provides tools like VS Code extension, UiMode, and Trace Viewer for writing, debugging, and running tests. Effective tests prioritize user-facing attributes, use playwright locators and assertions, and avoid testing third-party dependencies. Playwright simplifies testing by generating tests, providing code generation and UI mode, and allows for easy running and debugging of tests. It helps in fixing failed tests and analyzing DOM changes, fixing locator mismatches, and scaling tests. Playwright is open source, free, and continuously growing.

Workshops on related topic

Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
TestJS Summit 2023TestJS Summit 2023
148 min
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
Top Content
Workshop
Filip Hric
Filip Hric
Probablemente conozcas la historia. Has creado un par de pruebas y, como estás utilizando Cypress, lo has hecho bastante rápido. Parece que nada te detiene, pero luego - prueba fallida. No fue la aplicación, no fue un error, la prueba fue... ¿inestable? Bueno sí. El diseño de la prueba es importante sin importar la herramienta que utilices, incluyendo Cypress. La buena noticia es que Cypress tiene un par de herramientas bajo su cinturón que pueden ayudarte. Únete a mí en mi masterclass, donde te guiaré lejos del valle de los anti-patrones hacia los campos de pruebas estables y siempre verdes. Hablaremos sobre los errores comunes al escribir tu prueba, así como depurar y revelar problemas subyacentes. Todo con el objetivo de evitar la inestabilidad y diseñar pruebas estables.