Cómo es de verdad el calendario de una migración de Selenium

La situación en la que estaban

En septiembre de 2024, el equipo de ingeniería de Zenjob publicó en el Zenjob Tech Blog un relato de su migración de Selenium a Playwright. Las cifras con las que abrían eran las atractivas: unos tests que tardaban 35 minutos en ejecutarse ahora tardan unos 7.

El conjunto no era grande. Cien casos de prueba, repartidos en ocho jobs de Jenkins en paralelo. Para la mayoría de las organizaciones, es un conjunto de tamaño pequeño o medio. Muchos proveedores presupuestarían quince días para migrarlo.

Lo que motivó la migración no fue la velocidad, o no principalmente. El artículo del equipo es claro: la inestabilidad de los tests de Selenium «persistía» pese a añadir sincronización y datos de prueba dedicados, y exigía «retrabajo constante». Su configuración tampoco tenía informes integrados. Los ingenieros no solo ejecutaban tests; gestionaban todo un proceso de soporte alrededor de ellos para que siguieran sirviendo de algo.

Lo que hicieron de verdad

Antes de escribir un solo test de Playwright, Zenjob escribió un RFC. Compararon Selenium, Cypress y Playwright, expusieron su razonamiento y pasaron el documento a todo el equipo de ingeniería para que lo comentara. Solo cuando terminó ese proceso empezaron la migración.

Merece la pena detenerse en esto. Un RFC no es burocracia. Es el mecanismo con el que una migración se gana su presupuesto y construye su mandato. Cada ingeniero que más tarde revisará tests de Playwright, los mantendrá o los pondrá en duda durante un incidente ya ha sido invitado a entrar en el razonamiento. Eso tiene peso. El coste social de una migración (el tiempo y la energía necesarios para alinear a toda una organización en torno a un enfoque nuevo) es real, y casi nunca aparece en la estimación de nadie.

Una vez cerrado el RFC, el equipo ejecutó los dos conjuntos en paralelo: los tests de Selenium siguieron funcionando mientras se escribían los de Playwright, y el equilibrio fue cambiando poco a poco hasta poder retirar el conjunto antiguo. El artículo los describe «aumentando poco a poco los tests de Playwright y reduciendo los de Selenium». Es el enfoque cuidadoso. Evita un corte único y hace que el pipeline nunca dependa por completo de unos tests que el equipo aún no ha validado del todo.

También es caro, porque durante meses mantienes dos suites de tests a la vez.

Lo que les costó

Ocho meses. Para cien tests.

Esa cifra merece ser el titular de este texto, no una nota al pie. Zenjob no tardó ocho meses por desorganización o lentitud. Tardó ocho meses porque eso es lo que cuesta de verdad una migración hecha con cuidado: escribir y hacer circular el RFC, ejecutar ambos conjuntos en paralelo, mantener el pipeline en verde mientras el producto seguía saliendo, gestionar las sorpresas que aparecen a mitad de migración y, por último, retirar el conjunto de Selenium sin sobresaltos.

Los proveedores que venden herramientas de conversión automática suelen dar plazos medidos en días. Algunas comparativas de frameworks publicadas en internet usan plazos aún más cortos para conjuntos de tamaño similar. Conviene preguntar, con calma, qué incluyen esos plazos. Suelen cubrir la traducción mecánica de la sintaxis de los tests. Rara vez cubren el periodo en paralelo, el retrabajo de los datos de prueba o las semanas siguientes, cuando los ingenieros se enfrentan por primera vez a un framework nuevo en un pipeline real y los casos límite van saliendo de uno en uno.

El gráfico de abajo muestra el tiempo de ejecución antes y después, según los datos del equipo.

Tras la migración, el pipeline usaba ocho workers en paralelo; las ejecuciones locales, dos. El equipo informa de una reducción del 80 % en el tiempo de ejecución de los tests, de 35 minutos a unos 7. medido

Hubo un problema destacable durante la migración. La opción de configuración fullyParallel de Playwright, que activa el paralelismo completo entre todos los archivos de tests, hizo fallar algunos tests. El equipo la desactivó. Una vez desactivada, según el artículo, los tests lograron un «rendimiento estable».

Es una lección concreta y útil. fullyParallel es una de las funciones estrella de Playwright, y se cita a menudo para defender la migración. También es una función construida y probada con conjuntos nuevos, diseñados desde el principio para ejecutarse en paralelo. Un conjunto migrado arrastra supuestos de su vida anterior: sobre el orden de ejecución, sobre el estado compartido, sobre datos de prueba preparados pensando en ejecuciones secuenciales. Activar fullyParallel en un conjunto migrado es, en la práctica, un experimento. Zenjob hizo el experimento y vio que no funcionaba. Su solución fue desactivar la función, lo cual es un resultado razonable. Conviene señalar, eso sí, que las cifras de velocidad del artículo corresponden a unos tests que se ejecutan sin el paralelismo completo activado.

La cifra que no publicaron

El motivo declarado de la migración era la inestabilidad. La introducción describe una inestabilidad que persistía pese a las mejoras de sincronización y los datos de prueba dedicados, y la caracteriza como algo que exigía retrabajo constante. Está claro que es una parte importante de la razón por la que el equipo invirtió en migrar.

El artículo no publica una tasa de inestabilidad posterior a la migración.

No es una crítica al equipo ni al texto. La inestabilidad es realmente difícil de medir de forma que dé una cifra comparable. La velocidad es sencilla: comparas marcas de tiempo antes y después. La inestabilidad exige definir qué cuenta como fallo intermitente, elegir una ventana de medición lo bastante larga para ser representativa y controlar los cambios en los propios tests durante ese periodo. La velocidad te da un antes y un después limpios; la inestabilidad casi nunca.

Pero merece la pena nombrar el hueco como patrón. Los equipos migran en parte por la inestabilidad, e informan de la velocidad porque la velocidad se puede medir y la cifra es buena. Si estás evaluando una migración, la pregunta «¿cuánto más rápidos son los tests?» tiene una respuesta clara. La pregunta «¿cuánto más llevadero es el mantenimiento?» casi nunca la tiene, aunque suele ser la más importante.