Entradas de Lançamento Importam Mais do Que a Escolha do Modelo para Testes de TUI

Um levantamento de 197 aplicativos TUI no mundo real descobriu que apenas 12% do código de teste executa a interface de terminal — e 45% desses testes nunca enviam entrada, verificando um quadro renderizado estático em vez de impulsionar o app através da interação do usuário. Os números vêm de um artigo publicado em 4 de agosto de 2026 por pesquisadores da Universidade de Edimburgo e da Universidade de Ciência e Tecnologia do Sul, que transformaram os mesmos 197 aplicativos em um benchmark headless e testaram quatro LLMs de ponta contra ele junto com um explorador aleatório. As ferramentas são lançadas como tuibot e tuicov, ambas licenciadas por MIT e ambas no GitHub.

O benchmark abrange os quatro frameworks que dominam o desenvolvimento de TUI: ratatui (Rust), bubbletea (Go), textual (Python) e ink (TypeScript). Cada app é empacotado como uma imagem Docker instrumentada. tuibot lança a imagem, dá a ela um PTY headless via CLI shell-use da Microsoft, e envia uma das três estratégias de exploração no processo em execução: `random` (caos de teclado/mouse determinístico), `llm_guided` (loop de captura de tela-observar-agir), ou `llm_script` (leitura de código-fonte mais geração de script orientada por asserção). A cobertura — tanto de linhas quanto de widgets — é coletada por tuicov, que normaliza entre runtimes de linguagem e acumula entre relançamentos sem redefinir estado.

Sob orçamentos de tempo de parede iguais, nenhum LLM de ponta dominou a exploração aleatória para descoberta de crashes. A vantagem de crash do random é um efeito de throughput: ele cicla interações mais rápido por segundo. Por interação, a orientação de LLM é mais eficiente e alcança unicamente falhas com entrada condicionada — bugs que só surgem após uma sequência de entrada específica que um passeio aleatório tem pouca probabilidade de acertar primeiro. Para equipes que se importam com a classe de falha, não apenas com a contagem de crashes, a distinção importa: se você precisa verificar que um diálogo de confirmação bloqueia ações destrutivas, random é insuficiente.

O maior ganho prático único não veio da escolha de estratégia nem da seleção de modelo. Derivar automaticamente entradas de lançamento — descobrir quais argumentos e arquivos de entrada um app precisa para realmente iniciar — habilitou aplicativos que de outra forma nunca iniciavam sob testes automatizados. Apps que saem silenciosamente em caso de config ausente ou arquivo de entrada ausente nunca são explorados. Resolver o problema de lançamento superou todas as outras variáveis testadas.

A cobertura de linhas é um proxy fraco para descoberta de crashes. O artigo descobriu que números de cobertura correlacionam-se mal com se uma sessão encontrou um novo crash. Para equipes usando cobertura de linhas como um portão sim/não em testes de TUI, isso invalida a métrica. A cobertura de widgets, onde tuicov pode gravá-la confiável, ainda não é uma substituição — o artigo a sinaliza como pouco confiável em alguns frameworks.

A relevância prática é direta: Ink é o framework por trás de Claude Code (Anthropic) e Gemini CLI (Google), ambos usando Ink 6 com React 19 como sua camada TUI. Bubbletea v2, que enviou sua grande revisão arquitetônica este ano, fundamenta um conjunto crescente de agentes para desenvolvedores e CLIs baseados em Go. Qualquer equipe desenvolvendo uma ferramenta alimentada por LLM nesses frameworks agora tem um arnês para fuzz da camada TUI especificamente — não apenas da lógica de negócio abaixo.

A escolha de modelo é uma preocupação de segunda ordem. Testes automatizados de TUI são viáveis hoje usando tuibot, mas a parte difícil é resolvida antes de qualquer chamada de LLM — fazer o app iniciar, instrumentá-lo corretamente e escolher a métrica de crash certa. Uma vez que estão em vigor, `llm_guided` ganha seus custos de API apenas em caminhos condicionados por entrada que random não pode alcançar dentro do orçamento.