Construir un Metaframework en 30 Minutos o Menos

Hemos wipecoded nuestra aplicación muy rápido, 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 sumerja, una verificación rápida. ¿Podrían por favor levantar la mano si han 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 prueba de extremo a extremo muy popular. Es muy fácil de instalar. Con solo un comando, obtienes los navegadores predeterminados, configuración, prueba de ejemplo, e incluso acción de GitHub. 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 inicio, pruebas de componentes. Si, por alguna razón, no te gusta TypeScript, hay otras opciones también. Cuando las pruebas inevitablemente fallan, Playwright tiene la mejor experiencia de desarrollador en su clase con depurador incorporado, extensión de VS Code, capturas de pantalla, informes, videos, y mi favorito, el visor de trazas.

El visor de trazas es una solución integral para cualquier falla 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 IA. Playwright tiene un par de características de IA agradables, copiar error como prompt de IA, y el servidor Playwright MCP para permitir que los modelos de lenguaje grande se comuniquen con las APIs de Playwright. Permítanme darles una demostración rápida. Aquí, le 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. Como resultado, Courser genera un buen primer borrador, incluso para las charlas que aún no se han presentado. Muy genial. 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 listos para usar, 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 marca todas las casillas para facilitar las pruebas.

Al menos, eso es lo que pensé cuando hace un año, me uní a un equipo en Aetion, 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 empresarial altamente especializado y regulado que probablemente tiene un acrónimo para casi todo en el mundo. Permítanme darles un ejemplo. En la Clasificación Internacional de Enfermedades, eso es algo real, hay un código W6162xd que literalmente significa golpeado por un pato, encuentro subsiguiente. Y en tal dominio empresarial especializado, se pidió a nuestro equipo que cubriera todas las características principales con pruebas automatizadas para fines de regulación. El alcance incluía 64 épicas de pruebas.

Todavía recuerdo este número. Para un no profesional como yo, la interfaz de usuario 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 5 años y un back-end de Java de 10 años. Java tenía su propia historia pasando de monolito a microservicios, luego de regreso, dejándonos con un montón de APIs heredadas y obsoletas. 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, 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.

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 incitando a chat GPT, estúpida AI, nunca tomará mi trabajo. Está bien. Escribiré las pruebas. Al menos dime qué tipo de pruebas debo escribir. ¿Por dónde empiezo? Necesitábamos una estrategia de pruebas.

Ahora es el momento para un breve blog teórico. Probablemente la estrategia de pruebas 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 honesto. La otra opción es poner la pirámide al revés para obtener la pirámide de pruebas invertida. Si pongo un poco de helado encima, entonces obtenemos el cono de helado de pruebas. La estrategia de pruebas predeterminada para muchas empresas. No 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 y pone el enfoque principal en las pruebas de integración. Una evolución del diamante de pruebas que es más popular en la comunidad de Frontend es el trofeo de pruebas de Can'tSeeDots. 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 YesLint y TypeScript sean más explícitas. No todos saben, pero la estrategia favorita de Kian es el Dorito de pruebas de Tim Myers. 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. El sombrero del hongo se trata de pruebas de extremo a extremo. 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 razones aleatorias y era imposible averiguar qué estaba pasando. Era el momento de una acción de emergencia, a saber, documentación escrita. Al menos la parte de mejores prácticas.

Aparentemente, estábamos usando incorrectamente la API de Playwright, y aquí tengo un par de ejemplos para ustedes. 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, las dependencias de prueba. Como recordarán, estamos lidiando con un dominio de negocio bastante complejo. Un recorrido típico de usuario puede tomar varios minutos antes de lograr un resultado significativo. Y para el desarrollador, es tentador reutilizar resultados de pruebas anteriores para construir nuevas pruebas sobre ellos.

Desafortunadamente, esto 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 las pruebas lo más aisladas posible. Bueno, fácil de decir. Tuvimos que aplicarlo con un modo completamente paralelo e incrementar el número de trabajadores a tres para realmente ejecutar las pruebas en paralelo. Eso reveló algunos problemas que resolvimos.

Y con eso, finalmente, estábamos bien. 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 pasando al equipo de backend. El equipo de backend lo abre aparentemente en el modo oscuro, y no puede entender nada, al igual que probablemente ustedes, porque es demasiado pequeño. Así que nos lo devuelven. Y nosotros se lo devolvemos a ellos, y así sucesivamente.

Veamos el 63.1, problemas en la relación con los suegros. Aparentemente, nuestros informes de prueba no eran legibles en absoluto, y tuvimos que mejorarlos. Cuando se trata de hacer el código más legible, ya sabemos cómo hacerlo. Lo dividimos en bloques lógicos más pequeños. En las pruebas, hay un patrón común, page object model, 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.

Ya teníamos nuestro código organizado de esta manera, y aparentemente, estábamos a solo un paso de hacer nuestros informes igual de legibles. Y cuando digo un paso, lo digo literalmente con step decorator. Step decorator agrupa acciones de Playwright de bajo nivel en pasos de alto nivel, 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 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, de modo 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, estábamos 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.

Podrían bloquear la 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. Como recordatorio, estamos ejecutando pruebas en modo paralelo completo en tres workers. Y con solo un cambio de configuración, pasamos de 51 minutos a 17 minutos. Sí, simplemente aumentamos el número de workers.

Puedes 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 end-to-end con las pruebas de integración, las pruebas de integración generalmente se ejecutan más rápido porque omiten o mockean 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, mockeamos todas las solicitudes HTTP. Nuestra prueba era súper rápida, súper verde, 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 mocks? Mocking sin mocks, como lo llamo. Esto es exactamente lo que ofrece el plugin de Playwright network cache. Déjame mostrarte un ejemplo. Imagina que tenemos cinco pruebas lentas. Cada una comienza realizando alguna operación lenta. Digamos que abriendo un proyecto de prueba. Con Playwright network cache, la primera prueba realizará la operación, no importa si es get o post múltiples solicitudes o solo una, y almacenará el resultado en cache. Todas las demás pruebas reutilizarán ese cache como mocks. En nuestro caso, en realidad teníamos 200 pruebas como esa, 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 testing mushroom, nuestras pruebas de integración se encuentran dentro de la copa del hongo. Y podría hablar más y más sobre el testing mushroom, 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 testing mushroom 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 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 para el 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 feature-slice 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. ¿Son fáciles las pruebas? 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 bien tus pruebas. Y mi favorito. RS 202.5 obsesionado con las pruebas en React Summit 2025. Mi nombre es Kate. Estoy colaborando en redes sociales. Felices pruebas. Gracias. Tenemos Slido en funcionamiento. Y no olvides que puedes agregar tus preguntas mientras discutimos. Vamos a ver quién vota qué.

Pero, ¿por qué no comenzamos con los enfoques de pruebas? Así que pasaste por varios snacks diferentes que representan enfoques de pruebas. ¿Cuál crees que es el mejor? Creo que esa es una pregunta con asterisco. 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 favorito 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 mira alrededor porque hay algunas personas inteligentes que proponen algunas ideas interesantes. Absolutamente.

Pero creo que todos podemos estar de acuerdo en cuál es la estrategia de pruebas más linda, que obviamente es el hongo. No sé sobre el Dorito. Tal vez. Depende del sabor. Bien. Así que veamos. ¿Qué tal el paralelismo? Tenemos un par de preguntas sobre eso.

Entonces, ¿hay alguna manera de deshabilitar la paralelización para ciertas suites 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 cambiaría eso. Y nos forzamos a nosotros mismos en esta situación donde tuvimos que lidiar con el modo de paralelización completa y nos ayudó mucho a seguir las mejores prácticas y nos ayudó, ya sabes, a mantener a medida que avanza. Genial. Genial.

Y sobre ese mismo tema. Entonces, en los trabajadores paralelos, como cuántos, supongo, ya sabes, ¿cuántos usaste finalmente? O quizás la pregunta más amplia es ¿cómo determinas cuántos usar? ¿Y estabas ejecutando en CI en integración continua? Sí, sí. Por supuesto. Actualmente usamos 12 trabajadores en CI. No lo usamos en local, por ejemplo. En local, uso un máximo de cuatro trabajadores. Depende. 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í. Así que eso es básicamente lo que tienes. ¿Verdad? Genial.

Y entonces, ¿qué hay de esas pruebas de extremo a extremo 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 de extremo a extremo inestables? Esa es una gran pregunta. Así que si sigues las mejores prácticas de Playwright, entonces reduces, ya sabes, 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 de extremo a extremo 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 enfoques mixtos, como mencioné, con estas mismas pruebas de integración, cuando simulas algunas de esas cosas, este es el otro enfoque que puedes usar y puedes ser creativo. Sí.

Está bien. Tiene sentido. Así que de nuevo, hay que adaptarse a las circunstancias. ¿Verdad? Tienes que ser creativo para cualquier problema que se presente.

Está bien. Tenemos una pregunta sobre una cuestión muy específica. ¿Cuál es la diferencia entre at step y test dot step? Es lo mismo. 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 tus pruebas existentes, solo añades el decorador. Sí. Y eso tal vez sea una cuestión de preferencia personal de nuevo, como qué prefiere tu equipo. ¿Cuál es tu estilo? ¿Estás acostumbrado a trabajar con decoradores? ¿No lo estás? Genial.

Veamos. Están llegando muchas preguntas nuevas y geniales. Me encanta ver esto, aunque estamos teniendo un poco de discoteca silenciosa y así, ya sabes, es muy tranquilo en la vida real aquí. Todos estamos teniendo una interacción virtual increíble, lo que me lleva de vuelta a hace como cinco años atrás. ¿Alguien? ¿Vibras de 2020? Está bien. Entonces, de acuerdo. ¿Qué tal, cómo abordas, por ejemplo, las dependencias en el registro de usuarios sin repetir registros cada vez? Sí, esa es una gran pregunta. En primer lugar, tenemos datos de usuario de prueba preconfigurados como datos semilla que tenemos y ya contienen algunos usuarios de prueba. Así que probamos el registro solo una vez, pero luego usamos esos usuarios preconfigurados. Increíble.

Así que a medida que llegan las preguntas, no olviden que pueden votar por las que quieren escuchar respondidas, pero si su pregunta no es respondida, o si quizás estaban demasiado absortos en 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, volvamos a nuestra discoteca virtual, fiesta de discoteca silenciosa. Ojalá tuviéramos como patines o algo así, ¿no? ¿Solo yo? Estoy seguro de que nadie se lastimaría. Eso estaría bien.

Está bien. Hablando de inicios de sesión, supongo, y registro, ¿alguna idea sobre la optimización de generadores de inicio de sesión o funciones utilitarias que se ejecutarán para cada prueba? Así que 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? Está bien. La respuesta es bastante larga, así que hablemos después de la charla. En resumen, para el código repetido, usamos mucho los fixtures. Significan cosas diferentes en Playwright que en otras cosas. Y para la estabilidad, necesitamos hablar porque depende. Depende, ¿verdad? Depende. La espada más usada del ingeniero de software.

Absolutamente. Está bien. Creo que tenemos tiempo para un par de preguntas más, si están dispuestos. Estoy listo para Thunderstalk, honestamente. Así que vamos a terminar. Habrá más charlas en el escenario alternativo. Así que sí. Pero no se preocupen, si se pierden alguna de las charlas porque están, de nuevo, pasando un gran momento hablando en silencio sobre pruebas aquí, no se preocupen, las grabarán. Pueden verlas más tarde. Así que nos aseguraremos de ver eso. Y una vez que hayan tenido la oportunidad de calmarse también. Pero veamos, ¿estarían dispuestos a hacer una más para nuestra audiencia aquí? ¿Podemos obtener un woo virtual para animar esto? Absolutamente increíble. Fabuloso. Muy bien, veamos. Nuestra pregunta más popular al final es, ¿están usando Playwright sharding en las ejecuciones de CI y CD? Y si no, ¿por qué no? Simplemente no lo necesitamos.

Usamos una máquina grande. Tan pronto como lo necesitemos, lo usaremos porque sharding requiere un poco de ajuste de los informes. Así que necesitas fusionarlos de nuevo. Y no queremos hacer eso. ¿Podemos crecer lo suficiente? Lo haremos seguro. Así que de nuevo, dependiendo de la necesidad, ¿verdad? Como dependiendo de cuál sea tu capacidad real y cuál sea tu... Pero es una gran pregunta. Sí. Increíble. Increíble.

Bueno, me encanta que tengamos una discusión tan colorida sobre lo que ahora voy a pensar como una parte muy provocadora de hambre del desarrollo de software, la estrategia de pruebas. Así que, ¿podemos todos por favor dar un enorme, enorme agradecimiento virtual y real a la increíble Kate y todas las formas de prueba? Muchas gracias. Muchas gracias, Kate.