Las Entradas de Lanzamiento Importan Más Que la Elección del Modelo para Pruebas de TUI

Una encuesta de 197 aplicaciones TUI reales encontró que solo el 12% del código de prueba ejerce la interfaz de terminal en absoluto — y el 45% de esas pruebas nunca envían entrada, verificando un marco renderizado estático en lugar de impulsar la aplicación a través de la interacción del usuario. Los números provienen de un artículo publicado el 4 de agosto de 2026 por investigadores de la Universidad de Edimburgo y la Universidad de Ciencia y Tecnología del Sur, quienes convirtieron las mismas 197 aplicaciones en un benchmark headless y ejecutaron cuatro LLMs de frontera en su contra junto con un explorador aleatorio. Las herramientas se lanzan como tuibot y tuicov, ambas con licencia MIT y ambas en GitHub.

El benchmark abarca los cuatro frameworks que dominan el desarrollo de TUI: ratatui (Rust), bubbletea (Go), textual (Python) e ink (TypeScript). Cada aplicación se empaqueta como una imagen Docker instrumentada. tuibot lanza la imagen, le proporciona un PTY headless a través del CLI shell-use de Microsoft, y envía una de tres estrategias de exploración al proceso en ejecución: `random` (caos determinista de teclado/ratón), `llm_guided` (bucle de captura de pantalla-observar-actuar), o `llm_script` (lectura de código fuente más generación de script impulsada por aserciones). La cobertura — tanto de líneas como de widgets — se recopila mediante tuicov, que normaliza entre tiempos de ejecución de lenguaje y se acumula entre reinicios sin restablecer el estado.

Con presupuestos de tiempo de pared iguales, ningún LLM de frontera dominó la exploración aleatoria para el descubrimiento de fallos. La ventaja de fallo de random es un efecto de rendimiento: cicla interacciones más rápido por segundo. Por interacción, la guía de LLM es más eficiente y alcanza únicamente fallos controlados por entrada — errores que solo aparecen después de una secuencia de entrada específica que un paseo aleatorio es poco probable que encuentre primero. Para equipos que se preocupan por la clase de fallo, no solo por el recuento de fallos, la distinción importa: si necesita verificar que un cuadro de diálogo de confirmación bloquea acciones destructivas, random es insuficiente.

La ganancia práctica más grande vino de ninguna elección de estrategia ni selección de modelo. Derivar automáticamente entradas de lanzamiento — determinar qué argumentos y archivos de entrada necesita una aplicación para iniciarse realmente — habilitó aplicaciones que de otro modo nunca se inician bajo pruebas automatizadas. Las aplicaciones que salen silenciosamente con configuración faltante o archivo de entrada ausente nunca se exploran. Resolver el problema de lanzamiento superó todas las otras variables probadas.

La cobertura de líneas es un proxy débil para el descubrimiento de fallos. El artículo encontró que los números de cobertura se correlacionan mal con si una sesión encontró un nuevo fallo. Para equipos que utilizan cobertura de líneas como puerta de sí/no en pruebas de TUI, esto invalida la métrica. La cobertura de widgets, donde tuicov puede registrarla de manera confiable, aún no es un reemplazo — el artículo la marca como poco confiable en algunos frameworks.

La relevancia práctica es directa: Ink es el framework detrás de Claude Code (Anthropic) y Gemini CLI (Google), ambos utilizando Ink 6 con React 19 como su capa TUI. Bubbletea v2, que lanzó su gran revisión arquitectónica este año, subyace a un conjunto creciente de agentes para desarrolladores y CLIs basados en Go. Cualquier equipo que construya una herramienta impulsada por LLM en estos frameworks ahora tiene un arnés para fuzz de la capa TUI específicamente — no solo de la lógica empresarial debajo.

La elección de modelo es una preocupación de segundo orden. Las pruebas de TUI automatizadas son viables hoy en día utilizando tuibot, pero la parte difícil se resuelve antes de cualquier llamada de LLM — hacer que la aplicación se inicie, instrumentarla correctamente y elegir la métrica de fallo correcta. Una vez que están en su lugar, `llm_guided` gana sus costos de API solo en caminos controlados por entrada que random no puede alcanzar dentro del presupuesto.