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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.