Generación de autotests y localizadores con IA en un proyecto legacy: experiencia práctica

La autora continúa su serie práctica sobre la generación automática de pruebas. En este nuevo artículo explica cómo generó exactamente los autotests y los localizadores para un gran proyecto legacy, cuánto tiempo le llevó, dónde se equivocó el modelo y si mereció la pena.

Qué mostró la parte anterior de la serie

En su artículo anterior, la misma autora ya había llegado a una conclusión clave: sin un README que describa la arquitectura del framework de pruebas, generar autotests en un gran proyecto legacy se convierte en un ciclo interminable de revisiones y correcciones. Si el modelo no tiene contexto sobre cómo está construido el framework (qué clases base usar, cómo se organizan los localizadores, qué convenciones sigue el proyecto), propone una y otra vez código que hay que reescribir a mano, en lugar de ofrecer directamente un resultado funcional.

Esa conclusión sirve de marco para el nuevo texto: una vez cumplida la condición básica, la descripción de la arquitectura, la cuestión pasa a ser práctica. Precisamente por ahí arranca la autora, que promete mostrar no consejos abstractos, sino un proceso concreto de generación de autotests y localizadores sobre código real.

Dónde suele tropezar la generación de localizadores

Los localizadores son probablemente el punto más débil de la generación automática de pruebas de UI. Dependen del marcado concreto de la página, que en los proyectos legacy suele ser inestable, incoherente y carecer de documentación. Un modelo que genera localizadores sin entender a fondo la estructura real del DOM de una pantalla concreta corre el riesgo de proponer selectores frágiles: selectores que se rompen con el más mínimo cambio de maquetación o que duplican localizadores ya existentes en el proyecto en lugar de reutilizarlos.

Por eso la autora se centra en tres preguntas prácticas: cuánto tiempo ahorra realmente este enfoque frente a escribir las pruebas a mano, en qué escenarios el modelo sigue equivocándose incluso con un README de arquitectura y si compensa a la escala de un gran proyecto legacy, donde un error en las pruebas se paga con falsos positivos en la CI y con horas del equipo perdidas en analizarlos.

• Formato: segundo artículo de una serie sobre la generación de autotests y localizadores con IA
• Condición del primer artículo: el README con la descripción de la arquitectura del framework es imprescindible en un proyecto legacy
• Foco del nuevo artículo: el proceso concreto, el tiempo invertido y los errores típicos del modelo
• Objeto de las pruebas: un gran proyecto legacy

Qué significa esto

La experiencia de series como esta demuestra que, en la práctica, generar autotests con IA no se reduce a «lo pido y obtengo código que funciona». Exige un trabajo previo de preparación del contexto del proyecto y una valoración realista de en qué escenarios el ahorro de tiempo es real y en cuáles se ve compensado por la revisión manual y los ajustes del código generado.