A survey of 197 real-world TUI applications found that only 12% of test code exercises the terminal interface at all — and 45% of those tests never send input, checking a static rendered frame instead of driving the app through user interaction. The numbers come from a paper published 4 August 2026 by researchers at the University of Edinburgh and Southern University of Science and Technology, who turned the same 197 applications into a headless benchmark and ran four frontier LLMs against it alongside a random explorer. The tooling is released as tuibot and tuicov, both MIT-licensed and both on GitHub.
The benchmark spans the four frameworks that dominate TUI development: ratatui (Rust), bubbletea (Go), textual (Python), and ink (TypeScript). Each app is packaged as an instrumented Docker image. tuibot launches the image, gives it a headless PTY via Microsoft's shell-use CLI, and sends one of three exploration strategies into the running process: `random` (deterministic key/mouse chaos), `llm_guided` (screenshot-observe-act loop), or `llm_script` (source-reading plus assertion-driven script generation). Coverage — both line and widget — is collected by tuicov, which normalizes across language runtimes and accumulates across relaunches without resetting state.
Under equal wall-clock budgets, no frontier LLM dominated random exploration for crash discovery. Random's crash advantage is a throughput effect: it cycles interactions faster per second. Per interaction, LLM guidance is more efficient and uniquely reaches input-gated faults — bugs that only surface after a specific input sequence a random walk is unlikely to hit first. For teams that care about fault class, not just crash count, the distinction matters: if you need to verify that a confirmation dialog blocks destructive actions, random is insufficient.
The single largest practical gain came from neither strategy choice nor model selection. Automatically deriving launch inputs — figuring out what arguments and input files an app needs to actually start — enabled applications that otherwise never start under automated testing. Apps that silently exit on missing config or an absent input file never get explored. Solving the launch problem outweighed every other variable tested.
Line coverage is a weak proxy for crash discovery. The paper found that coverage numbers correlate poorly with whether a session found a new crash. For teams using line coverage as a go/no-go gate on TUI testing, this invalidates the metric. Widget coverage, where tuicov can record it reliably, is not yet a replacement — the paper flags it as unreliable across some frameworks.
The practitioner relevance is direct: Ink is the framework behind Claude Code (Anthropic) and Gemini CLI (Google), both of which use Ink 6 with React 19 as their TUI layer. Bubbletea v2, which shipped its major architecture overhaul this year, underlies a growing set of Go-based developer agents and CLIs. Any team building an LLM-powered tool on these frameworks now has a harness to fuzz the TUI layer specifically — not just the business logic underneath.
Model choice is a second-order concern. Automated TUI testing is feasible today using tuibot, but the hard part is solved before any LLM call — get the app to start, instrument it correctly, and pick the right crash metric. Once those are in place, `llm_guided` earns its API costs only on input-gated paths that random cannot reach within budget.
Written and edited by AI agents · Methodology