** Интеграционное тестирование для терминальных программ, как вы бы тестировать веб ** Терминалы порождают ваш реальный двоичный файл в реальном псевдотерминале, рендерах его вывод через эмулятор VT в сетку экрана в памяти и позволяет Тестируйте ожидание, утверждение против и снимите эту сетку — что бы сделал пользователь Смотри, а не байты, которые его произвели.

Рецепт мгновенного тестирования Рататуи включает в себя пример терминов для тестирования скомпилированного приложения через PTY. Используйте его вместе со снимками TestBackend, чтобы охватить взаимодействия и процессы. поведение.

Почему

В процессе тестирования виджет превращает вашу функцию draw в буфер. Это Он может быть быстрым и точным, и он не может видеть ничего между T2 и пользователем. Глаза. Терминал является вторым слоем для небольшого количества сквозных потоков. Через реальную двоичную систему:

** Терминальное состояние** — сырой режим и введённый и оставленный альтернативный экран, Курсор восстанавливается после q или паники, режимы приложения поворачиваются Включено ли оно и выключено ли оно. ** То, что на самом деле нарисовано** — рисунок коробки, цвета, широкие символы, а Поле пароля, которое скрыто, а не напечатано в чистом виде

termlens

Integration testing for terminal programs, the way you would test a web app. termlens spawns your real binary in a real pseudo-terminal, renders its output through a VT emulator into an in-memory screen grid, and lets a test wait on, assert against and snapshot that grid — what a user would see, not the bytes that produced it.

Ratatui’s snapshot-testing recipe includes a termlens example for testing a compiled application through a PTY. Use it alongside TestBackend snapshots to cover interactions and process behaviour.

Why

An in-process widget test renders your draw function into a buffer. It is fast and precise, and it cannot see anything between draw and the user’s eyes. termlens is the second layer, for a small number of end-to-end flows through the real binary:

• Terminal state — raw mode and the alternate screen entered and left, the cursor restored after q or a panic, the modes the application turned on and whether it turned them off.
• What is actually drawn — box drawing, colours, wide characters, a password field that is concealed rather than printed in clear, a stray println! or panic message that never went through the framework.
• Real input and real signals — keys, mouse and paste encoded exactly as the terminal encodes them under the modes the application enabled; a SIGWINCH that the application must survive.
• Behaviour that changes no cell — a repaint that drew nothing, a bell on a rejected key, an image that went out as pixels when it should have been text.

Every wait is deadline-bounded, and every failure carries the screen: a CI log shows what the application was displaying, not assertion failed: false.

Quick start

cargo add termlens --dev
cargo add insta --dev    # used by the snapshot assertions below

use std::time::Duration;
use termlens::{Key, Terminal};

#[test]
fn quits_from_the_main_screen() -> termlens::Result {
    let mut t = Terminal::builder()
        .size(80, 24)
        .env_clear()                       // hermetic: no host env leaks in
        .timeout(Duration::from_secs(5))   // every wait_* has this deadline
        .spawn(env!("CARGO_BIN_EXE_myapp"))?;

    // Wait for the app's ready marker, let the picture settle, then snapshot
    // it with its styles — the three decisions every TUI snapshot needs.
    termlens::assert_screen_snapshot!(t, after = |s| s.contains("Ready"));