Can LLMs Test Terminal User Interfaces?

Imagina que eres un desarrollador de videojuegos. Has construido un mundo hermoso y complejo con montañas, ciudades y personajes, pero olvidaste probar si las puertas realmente se abren o si el jugador se queda atrapado en una pared. En el mundo del software, esto es una pesadilla. Para prevenirlo, los programadores utilizan "probadores automatizados" (automated testers): asistentes robóticos que hacen clic en botones, escriben comandos e intentan romper el software para encontrar errores antes que los usuarios reales.

Durante mucho tiempo, hemos tenido dos tipos principales de software para probar. Primero, están las Interfaces de Usuario Gráficas (GUI), como las aplicaciones en tu teléfono o computadora. Estas son como habitaciones elegantes y coloridas con puertas, ventanas y botones etiquetados. Los probadores pueden preguntarle fácilmente a la computadora: "¿Dónde está el botón 'Inicio'?" y hacer clic. Segundo, están las Interfaces de Línea de Comandos (CLI), que son como telégrafos de la vieja escuela. Escribes un código secreto y la computadora te responde con texto. Estas son fáciles de probar porque son simples: escribe esto, obtén aquello.

Pero hay un tercer tipo de software, más escurridizo, llamado Interfaz de Usuario de Terminal (TUI). Piensa en estas como aplicaciones "retro-futuristas". Se ven como los viejos telégrafos (solo texto sobre una pantalla negra), pero actúan como las habitaciones elegantes. Tienen cursores en movimiento, menús emergentes y estados complejos que cambian a medida que escribes. Son populares entre hackers, administradores de sistemas e incluso asistentes de codificación con IA. El problema es que no sabemos cómo probarlas adecuadamente. Son demasiado complejas para los probadores de telégrafos simples, pero carecen de los "botones etiquetados" que necesitan los probadores de habitaciones elegantes. Este artículo plantea una gran pregunta: ¿Pueden los robots de Inteligencia Artificial (IA) modernos aprender a probar estas complicadas aplicaciones de texto, o están tan confundidos como nosotros?

---

La Gran Historia de Detectives de las TUI

Los investigadores detrás de este artículo decidieron jugar a ser detectives. Reunieron una colección masiva de 197 aplicaciones TUI del mundo real —desde gestores de archivos hasta monitores de sistema— y las sometieron a una rigurosa prueba de estrés. Pero primero, tenían que resolver un misterio: ¿Qué tan bien se están probando estas aplicaciones actualmente?

Echaron un vistazo al código de estas 197 aplicaciones y encontraron un secreto impactante. Solo alrededor del 12% del código de prueba realmente intentaba interactuar con la pantalla. Peor aún, casi la mitad de las pruebas que sí tocaban la pantalla nunca escribieron una sola tecla. Solo verificaban si la pantalla se veía bien cuando la aplicación se abría por primera vez, como revisar la pintura de un coche pero sin encender nunca el motor. Resulta que la mayoría de las TUI se están probando con los ojos cerrados.

Así que el equipo construyó sus propias herramientas para ver qué pasaría si dejaran sueltos a la IA y al azar en estas aplicaciones. Crearon un laboratorio "headless" (una computadora sin pantalla, solo una terminal virtual) y empaquetaron cada aplicación en un contenedor especial. Luego organizaron una carrera entre cuatro estrategias diferentes:

1. El Mono Aleatorio: Un robot que simplemente escribe teclas al azar lo más rápido que puede.
2. La Guía de IA: Un modelo de lenguaje extenso (LLM) inteligente que mira la pantalla y decide qué escribir a continuación.
3. La Guía de IA con un Mapa: El mismo robot inteligente, pero esta vez también descifró los "códigos de lanzamiento" (argumentos) correctos para que las aplicaciones se iniciaran correctamente.
4. El Guionista de IA: Un robot que lee el código fuente y escribe un plan de prueba antes de comenzar.

Ejecutaron estas estrategias contra las 197 aplicaciones, dándole a cada una exactamente 600 segundos (10 minutos) para encontrar errores.

Los Resultados: ¿Quién Gana?

Los resultados fueron sorprendentes y un poco contraintuitivos.

1. El robot "inteligente" no es el más rápido.
Cuando los investigadores observaron cuántos errores encontraba cada estrategia por ejecución, el Mono Aleatorio fue el que encontró más fallos de ejecución (crashes). ¿Por qué? Porque era increíblemente rápido. En 600 segundos, el robot aleatorio pudo escribir cientos de teclas. Los robots de IA, siendo reflexivos e "inteligentes", pasaron la mayor parte del tiempo pensando y esperando sus respuestas, por lo que solo lograron escribir una docena de teclas en el mismo tiempo.

2. Pero el robot "inteligente" es mucho más eficiente.
Aquí está el giro: si mides qué tan bueno son por pulsación de tecla, los robots de IA fueron 13 veces mejores que el mono aleatorio. El mono aleatorio solo estaba lanzando dardos a ciegas y acertando por suerte. Los robots de IA estaban apuntando con cuidado. Fueron capaces de encontrar de forma única errores de "entrada bloqueada" (input-gated bugs): fallos que solo ocurren si escribes una secuencia específica de teclas para desbloquear un menú oculto. El mono aleatorio nunca descifró el código, pero la IA sí.

3. El "Código de Lanzamiento" fue el verdadero héroe.
El mayor avance no fue la inteligencia de la IA; fue su capacidad para descubrir cómo iniciar las aplicaciones. Muchas TUI necesitan archivos o argumentos específicos para siquiera abrir su interfaz. Sin estos, simplemente se cierran. La estrategia que utilizó la IA para derivar automáticamente los inputs de lanzamiento encontró la mayor cantidad de errores y cubrió la mayor parte del código. Resulta que no puedes probar un coche si no sabes cómo girar la llave.

4. La trampa de los "Crashes".
Los investigadores también descubrieron una trampa importante en la forma en que solemos contar los errores. Encontraron que el 82% de los "crashes" (programas que se detienen inesperadamente) eran en realidad programas diciendo: "¡Oye, necesito un archivo!" o "¡Se me ordenó detenerse!". Estos no son errores reales; son solo comportamientos normales. Si solo cuentas cada vez que un programa se detiene, obtienes una falsa alarma. El equipo tuvo que construir un "detector de crashes" especial que analiza el texto real en la pantalla para ver si es un error real o simplemente una salida cortés. Una vez que filtraron el ruido, encontraron 179 errores reales y válidos en las 197 aplicaciones.

5. Más cobertura de código $\neq$ Más errores.
En las pruebas de software, la gente suele creer que si cubres más líneas de código, encuentras más errores. El artículo sugiere que esto no es cierto para las TUI. Encontraron que las pruebas que encontraban más fallos de ejecución a menudo tenían menor cobertura de código. ¿Por qué? ¡Porque encontrar un fallo detiene la prueba inmediatamente! La prueba se corta, por lo que nunca llega a cubrir el resto del código. Esto significa que para las TUI, contar cuántas líneas de código fueron tocadas es una mala forma de medir qué tan buena es una prueba.

La Conclusión

El artículo concluye que las pruebas automatizadas para estas interfaces basadas en texto son posibles, pero están lejos de estar resueltas. Ningún modelo de IA fue el claro ganador; de hecho, un simple probador aleatorio fue competitivo porque era más rápido. La verdadera clave del éxito fueron las estrategias híbridas: usar la IA para descubrir cómo iniciar la aplicación y navegar hacia el estado correcto, y luego usar el testeo aleatorio de alta velocidad para estresar la interfaz.

Los autores también nos advierten que necesitamos mejores herramientas. La forma actual de probar (solo verificar si el programa se detiene) está llena de falsas alarmas. Liberaron sus propias herramientas, tuicov y tuibot, para ayudar a otros a probar estas aplicaciones adecuadamente. El mensaje es claro: las TUI son una parte enorme y creciente de nuestro mundo de software, pero actualmente son el "viejo oeste" de las pruebas. Tenemos las herramientas para empezar a domesticarlas, pero necesitamos dejar de confiar en las reglas antiguas y empezar a diseñar pruebas que entiendan la naturaleza única y basada en texto de estas interfaces.