.agents/skills/tui-tests/SKILL.md
crates/but/src/command/legacy/status/tui/tests/crates/but/src/command/legacy/status/tui/tests/utils.rscrates/but/src/command/legacy/status/tui/tests/snapshots/#[test]
fn describes_behavior_under_test() {
let env = Sandbox::init_scenario_with_target_and_default_settings("one-stack").unwrap();
env.setup_metadata(&["A"]).unwrap();
let mut tui = test_tui(env);
tui.input_then_render(KeyCode::Down)
.assert_rendered_term_svg_eq(file!["snapshots/describes_behavior_under_test_001.svg"]);
}
Useful input examples:
tui.input_then_render(None); // render without inputs
tui.input_then_render('j'); // single char input
tui.input_then_render(KeyCode::Down); // special key
tui.input_then_render((KeyModifiers::SHIFT, KeyCode::Char('J'))); // keys with modifiers
tui.input_then_render([KeyCode::Down, KeyCode::Down]); // multiple keys from array
tui.input_then_render("commit message text"); // multiple keys from string
tui.reload(); // reload state after making external changes
Generally prefer
assert_current_line_eq(str![...]) for cursor/selection behavior.assert_rendered_term_svg_eq(file!["snapshots/test_function_name_001.svg"])
for everything else.Generally you should include one assert_rendered_term_svg_eq per logical
group of inputs, to catch bad states early.
Be careful using assert_rendered_contains and assert_rendered_not_contains
since they might lead to false positives. They're intended to use while
iterating on a test where snapshots would cause too much churn.
Read crates/but/src/command/legacy/status/tui/tests/utils.rs for more
specialized assertions.
cargo test -p but <test-name> to run one test.SNAPSHOTS=overwrite cargo test -p but <test-name> to run and update
snapshots.cargo test -p but tui to run all tui tests. Do this after changing
things.If a test fails the output will include the rendered state of the test backend. This can be used when iterating on a test as a way of inspecting the state.