Dos semanas, 200 tests y la parte que todos se saltan

Qué les hizo cambiar

Lingvano es una app austriaca para aprender lengua de signos. En octubre de 2023, su suite de tests end-to-end había crecido hasta superar los 200 tests de Cypress. La queja del equipo no era que Cypress hubiera fallado de forma catastrófica; eran cuatro limitaciones concretas que, juntas, los iban desgastando.

Las ejecuciones locales eran tan lentas que los ingenieros aislaban tests con marcadores .only durante el desarrollo: una forma de trabajar que resuelve el problema inmediato y acumula deuda sin hacer ruido. Cada marcador que se queda en el código es un test que ya no se ejecuta por defecto, y un conjunto con suficientes marcadores puede alejarse mucho de cubrir la aplicación real. El sharding, el remedio obvio para unos tests lentos, estaba detrás del plan de pago de Cypress. El soporte de WebKit figuraba como experimental. Lisa Weilguni, que publicó el relato del equipo en el blog de ingeniería de Lingvano en octubre de 2023, concluyó que la combinación justificaba el cambio.

La herramienta de IA que llegó primero

Antes de dar con un método que funcionara, el equipo probó GPT-4 para la conversión. El resultado se describe sin rodeos en el artículo:

«Sugería aserciones inexistentes y sintaxis obsoleta».

Abandonaron ese enfoque. Es la frase más útil del artículo, y es fácil pasarla por alto.

GPT-4 no produjo un resultado ininteligible. Produjo código de Playwright de apariencia plausible: código que llamaba a métodos de la API con el estilo correcto y que fallaba solo porque esos métodos no existen. Ese es el modo de fallo que importa. Una herramienta que genera tonterías evidentes se detecta en la primera revisión. Una herramienta que genera código erróneo con aspecto seguro se detecta al ejecutar los tests, o después del merge, o nunca si la cobertura original era escasa.

Que GitHub Copilot, usado en línea junto a la herramienta de migración de Playwright y conversores de terceros, lo hiciera mejor no es una cuestión de calidad del modelo. Es una cuestión de contexto. Copilot, trabajando sobre los archivos reales, ve los imports de alrededor, la versión de Playwright que se usa de verdad y los patrones de aserción que ya hay en el proyecto. Un prompt suelto a GPT-4 solo ve lo que le pones. El modelo que da mejores resultados suele ser el que ha recibido más contexto verificado con el que acotar sus sugerencias.

Lo que hicieron de verdad, y por qué se cumplió el plazo

El flujo final combinó tres cosas: GitHub Copilot para sugerencias en línea mientras el equipo recorría los archivos de tests, la herramienta de migración de Playwright para las transformaciones estructurales sencillas y conversores de terceros para el resto del trabajo mecánico. El equipo pasó los más de 200 tests en unas dos semanas.

Dos semanas fueron posibles aquí por razones que conviene nombrar. La suite de tests tenía un tamaño conocido y acotado. El equipo entendía la aplicación. Y Cypress y Playwright se parecen lo bastante en sintaxis como para que muchos tests se tradujeran con poco trabajo manual. Otros calendarios de migración publicados varían enormemente según la antigüedad de los tests, el lenguaje de origen y lo acopladas que estén a las tripas del framework. Una migración desde Selenium en Java, o desde un conjunto construido durante muchos años con mucha infraestructura propia, no compartirá estas características. Dos semanas es un resultado real en un contexto concreto, no una referencia general.

Las dos cifras, y por qué necesitas ambas

El título del artículo dice 70 %. Esa cifra sale de la ejecución local.

La ejecución local bajó de 1 minuto 27 segundos a 25 segundos. medido

La duración en CI bajó de 6 minutos 38 segundos a 3 minutos 43 segundos. medido

La mejora en local es del 71 %, que el título del artículo redondea a 70 %. Para un titular, es una decisión editorial defendible. La mejora en CI es del 44 %. La distancia entre ambas cifras no es un error de redondeo. Es estructural.

Una ejecución local mide lo que el framework controla directamente: el arranque del proceso, la inicialización del navegador y la ejecución de los tests. Cuando Playwright hace eso con más eficiencia que Cypress, el ahorro se ve entero. Un pipeline de CI contiene todo eso, más el checkout, la instalación de dependencias, los pasos de compilación, la subida de artefactos y los informes. Playwright no toca nada de eso. La parte del tiempo de tu pipeline que queda fuera del ejecutor de tests no se mueve en absoluto. Cuanta más sobrecarga tenga tu pipeline, menor será la mejora neta visible.

Un responsable que lee «un 70 % más rápido» y construye un caso de reducción de costes sobre esa cifra se encontrará con un 44 %. Es una consecuencia previsible de medir un cambio de framework contra un pipeline completo, y es exactamente el tipo de expectativa incumplida que, a posteriori, daña la confianza en un proyecto. Las dos cifras deberían citarse siempre juntas.

Lo que no significaban los tests en verde

Una vez que los tests pasaban, aparecieron dos problemas nuevos.

El soporte de WebKit (uno de los grandes argumentos de Playwright frente a Cypress) resultó ser, en palabras de Weilguni, «bastante lento e inestable en nuestro pipeline de GitHub CI», aunque funcionaba bien en local en un Mac. Es un patrón conocido: el WebKit de Playwright funciona sobre un port compilado y no sobre un navegador del sistema, y su comportamiento en un CI con Linux puede diferir del de un entorno macOS nativo. El equipo ganó cobertura en varios navegadores, pero heredó un trabajo de mantenimiento que no había previsto.

La limitación más importante fue Mock Service Worker. El equipo usaba MSW para interceptar peticiones de red en sus tests de Cypress. Playwright, como señala Weilguni, no admite MSW en el contexto de la ventana, lo que obligó al equipo a abandonar su configuración de MSW en favor de la interceptación de red integrada en Playwright.

MSW es un buen ejemplo de un patrón más amplio: dependencias de herramientas que parecen secundarias hasta que migras, y entonces o no están soportadas o exigen una estrategia de sustitución completa. La auditoría útil antes de migrar no se limita a los archivos de tests. Abarca cada librería de la que dependen esos tests, con una respuesta clara sobre el camino de cada una en el nuevo entorno.