Kibana es conocido por ser uno de los monorepositorios públicos más grandes en GitHub, con más de tres millones de líneas de código en TypeScript y una comunidad activa que supera los 150 contribuyentes mensuales. Mantener un proyecto de esta magnitud implica una batería continua de actualizaciones, mejoras y mantenimiento, incluyendo la importante tarea de mantener las dependencias externas al día. La actualización de @testing-library/user-event de la versión 13 a la 14 representa un ejemplo claro de los desafíos y aprendizajes que emergen al integrar nuevos paradigmas en un ecosistema tan extenso. Esta actualización no fue algo trivial. Afectó 401 archivos e implicó más de cinco mil inserciones y casi cinco mil eliminaciones, lo que requirió la revisión y aprobación de más de veinte equipos responsables de distintas partes del código.
A pesar de que la versión 14 fue lanzada en marzo de 2022, la incorporación a Kibana no se efectuó hasta septiembre de 2024, lo que evidencia la realidad del tech debt o deuda técnica en proyectos de gran escala. Más allá de modernizar una dependencia, esta experiencia pone sobre la mesa la gestión de mantenimiento técnico y cómo las actualizaciones pueden convertirse en una labor tan compleja como necesaria. Uno de los cambios más significativos en user-event v14 fue la introducción de métodos que retornan promesas. Esto obliga a que las llamadas a funciones como click, type o keyboard sean aguardadas mediante await, modificando patrones de escritura en los tests que, hasta entonces, ejecutaban de manera síncrona. Este cambio trajo consigo además una revisión profunda en la forma en que se manejan los eventos de puntero, reemplazando configuraciones anteriores por nuevas formas de saltarse algunas validaciones que son ahora más estrictas y realistas en términos de la interacción del usuario con la interfaz.
La manera en que los eventos de propagación y burbujeo se comportan ahora es más fiel al comportamiento real del navegador. Esto supuso un doble filo: por un lado, mayor precisión en las pruebas; por otro, la aparición de bugs ocultos que se manifestaron al contrastar con los test existentes. Estos descubrimientos obligaron a revisar y ajustar una gran cantidad de casos para asegurar la coherencia y robustez en las pruebas de interacción. Entre los desafíos más inesperados estuvo la ralentización notable en el rendimiento del conjunto de pruebas. Los test que implicaban escritura o tipeo se volvieron significativamente más lentos, generando incluso timeouts que no se habían presentado con versiones anteriores.
Este problema no es exclusivo de Kibana, sino que ha sido reportado en otras comunidades que han efectuado la misma migración a la versión 14. Para mitigar el impacto en la velocidad, se implementaron diferentes soluciones. La desactivación de la demora artificial al escribir mediante la configuración { delay: null } resultó efectiva para optimizar tiempos. Asimismo, limitar la profundidad de las verificaciones de eventos puntero mediante pointerEventsCheck se tradujo en una aceleración importante en la ejecución de ciertos eventos como click. En casos críticos, se recurrió temporalmente a fireEvent, una alternativa menos realista pero más rápida, para no bloquear el avance del desarrollo.
Los mantenedores de la biblioteca subrayan que priorizar la simulación de un comportamiento realista del usuario es una elección deliberada, aunque ello implique sacrificios en la velocidad de las pruebas. En el contexto de grandes bases de código, esto se traduce en la necesidad de ajustar los tiempos de espera y repensar la manera en que se realizan ciertas pruebas, especialmente en componentes con formularios complejos y flujos de interacción extensos. Este efecto colateral tiene además costos organizativos, pues incrementa el tiempo total que se invierte en las ejecuciones de CI y ralentiza el ciclo de desarrollo. La complejidad no termina en el rendimiento. La migración en sí misma constituyó un arduo proceso manual.
En un ambiente con miles de pruebas escritas bajo antiguos patrones, un codemod automatizado resultó insuficiente para cubrir todos los casos límite, particularmente en contextos personalizados y test harnesses específicos implementados por distintos equipos. Este proceso implicó cambiar estructuras fundamentales en los tests. Ejemplos claros incluyen la conversión de llamadas sin await a versiones que ahora requieren espera explícita para resolverse, el ajuste en los parámetros de funciones para adaptarse a nuevas opciones ligadas a la gestión de eventos, así como modificaciones en la manera de esperar la desaparición de elementos en pantalla, moviéndose de utilidades especializadas a bloques await que contienen expectativas dentro de funciones de espera. Otra transformación relevante estuvo ligada al manejo de eventos de teclado, cuya sintaxis fue actualizada para alinearse mejor con los estándares. También se eliminó la necesidad de envolver las llamadas de eventos en act, ya que las funciones ahora se responsabilizan automáticamente de gestionar el ciclo de vida necesario para la actualización del DOM y la sincronización con React.
El API para eventos de pegar sufrió una revisión importante. Anteriormente, se podía pegar directamente sobre un elemento con un solo llamado, pero con la versión 14, se debe primero simular un click para focalizar el elemento y luego invocar la acción de pegar. Esto representa un cambio en la filosofía de la simulación de interacción, más fiel a lo que sucede en un navegador real. Todo este proceso brindó una oportunidad invaluable para revisar y aprender de una evolución natural en las prácticas de testing. La mirada arqueológica hacia años de patrones escritos por múltiples equipos permitió identificar áreas donde el código podía ser modernizado y estandarizado.
Más allá de las dificultades técnicas, el esfuerzo fue altamente valorado por la comunidad interna, incrementando la calidad y mantenibilidad del proyecto a largo plazo. Aunque la experiencia haya sido ardua, refleja un escenario común en proyectos de gran escala: la actualización de dependencias esenciales no es sólo un reto técnico, sino también organizacional y cultural. La lección principal consiste en prepararse para una transición que puede requerir ajustes en múltiples capas, desde la tecnología hasta las prácticas de equipo y los tiempos de ejecución. El impacto de esta actualización no solo se limita a Kibana o su equipo de desarrolladores. Muchos proyectos que aún utilizan versiones anteriores de user-event podrían encontrar útiles estas experiencias para anticipar problemas o planificar su propia migración con mayores chances de éxito.
La reflexión sobre el equilibrio entre realismo en las pruebas y eficiencia en el pipeline puede conducir a nuevas estrategias que combinen ambas necesidades de manera más efectiva. En definitiva, la actualización de user-event a su versión 14 en Kibana ejemplifica las complejidades de mantener un ecosistema de pruebas estable y eficiente en aplicaciones grandes y dinámicas. Este caso destaca la importancia de documentar los desafíos, compartir aprendizajes y continuar evolucionando las herramientas y métodos para mantener la calidad en el desarrollo de software moderno.
