rtk 测试专项指南快照测试、Token 节省量化验证与跨平台 Shell 兼容性测试【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk本文基于 RTK 仓库中的测试专项 Agent 定义文档 rtk-testing-specialist.md系统讲解 RTK一个将常见开发命令输出压缩 60-90% token 消耗的 Rust CLI 代理特有的四类测试体系基于insta的输出快照测试、以真实 fixture 量化 token 节省率的准确性验证、跨平台macOS/zsh、Linux/bash、Windows/PowerShellShell 转义测试以及执行真实命令的集成测试。读完后你将掌握为新 filter 编写完整测试的标准工作流、cargo insta快照审查流程以及如何在 CI 中守住“60% 节省率发布红线”。测试专项 Agent 的定位与核心职责RTK 在.claude/agents/目录下为 Claude Code 定义了多个子代理其中 rtk-testing-specialist.md 专门面向 RTK 的独特测试需求命令输出验证、token 计数准确性、跨平台 Shell 兼容性。该 Agent 的 frontmatter 声明如下--- name: rtk-testing-specialist description: RTK testing expert - snapshot tests, token accuracy, cross-platform validation model: sonnet tools: Read, Write, Edit, Bash, Grep, Glob ---五大核心职责快照测试Snapshot testing使用instacrate 做输出验证Token 准确性Token accuracy用真实 fixture 验证 60-90% 的节省声明跨平台Cross-platform测试 bash/zsh/PowerShell 兼容性回归防护Regression prevention在 CI 中检测性能退化集成测试Integration tests执行真实命令git、cargo、gh、pnpm 等。从源码结构看这套职责与仓库实际布局高度对应各生态命令 filter 位于 src/cmds/ 下git、cargo、gh、js、python 等约 9 个生态共享工具函数如count_tokens位于 src/core/utils.rs真实命令输出 fixture 集中在 tests/fixtures/而 tests/ 根目录下的guard_integration_test.rs、pipeline_stdin_test.rs、copilot_selfheal_test.rs等则是跨模块的集成测试。快照测试模式以insta为主力策略文档明确insta快照测试是 filter 输出的首要测试策略。其基本用法是use insta::assert_snapshot; #[test] fn test_git_log_output() { let input include_str!(../tests/fixtures/git_log_raw.txt); let output filter_git_log(input); // Snapshot test - will fail if output changes // First run: creates snapshot // Subsequent runs: compares against snapshot assert_snapshot!(output); }工作机制是首次运行创建快照基线后续每次运行都将当前输出与快照比对输出格式一旦发生变化无论有意还是意外测试即失败从而捕获对 LLM 上下文格式的非预期改动。标准工作流四步写测试在测试中加入assert_snapshot!(output);跑测试cargo test首次运行会创建新快照审查快照cargo insta review交互式审查接受变更确认输出正确后执行cargo insta accept。适用时机所有新 filter——每个 filter 至少应有一个快照测试输出格式变更——修改 filter 逻辑时回归检测——捕获非预期的输出变化。一个完整的“从零添加快照测试”操作示例# 1. Create fixture echo raw command output tests/fixtures/newcmd_raw.txt # 2. Write test cat src/newcmd_cmd.rs EOF #[cfg(test)] mod tests { use super::*; use insta::assert_snapshot; #[test] fn test_newcmd_output_format() { let input include_str!(../tests/fixtures/newcmd_raw.txt); let output filter_newcmd(input); assert_snapshot!(output); } } EOF # 3. Run test (creates snapshot) cargo test test_newcmd_output_format # 4. Review snapshot cargo insta review # Press a to accept, r to reject # 5. Snapshot saved in snapshots/ ls -la src/snapshots/需要说明的是快照文件按模块就近存放如 git 模块的快照放在src/cmds/git/snapshots/这与下文“测试组织”一节一致。仓库贡献规范 CONTRIBUTING.md 也印证了这一测试分层单元测试内嵌模块#[cfg(test)]、快照测试由 filter 模块创建、集成测试通过#[ignore]标记并以cargo test --ignored单独运行。Token 节省率量化验证60-90% 承诺的测试护栏RTK 的核心产品承诺是 60-90% 的 token 节省因此文档要求所有 filter 必须在测试中量化验证节省率#[cfg(test)] mod tests { use super::*; // Helper function (add to tests/common/mod.rs if not exists) fn count_tokens(text: str) - usize { // Simple whitespace tokenization (good enough for tests) text.split_whitespace().count() } #[test] fn test_token_savings_claim() { let fixtures [ (git_log, 0.80), // 80% savings expected (cargo_test, 0.90), // 90% savings expected (gh_pr_view, 0.87), // 87% savings expected ]; for (name, expected_savings) in fixtures { let input include_str!(format!(../tests/fixtures/{}_raw.txt, name)); let output apply_filter(name, input); let input_tokens count_tokens(input); let output_tokens count_tokens(output); let savings 100.0 - (output_tokens as f64 / input_tokens as f64 * 100.0); assert!( savings expected_savings, {} filter: expected ≥{:.0}% savings, got {:.1}%, name, expected_savings * 100.0, savings * 100.0 ); } } }关键公式为savings 100.0 - (output_tokens / input_tokens * 100.0)其中 token 采用简单的空白分词split_whitespace().count()即可满足测试精度需求。文档强调如果节省率跌破 60%这是发布阻断项release blocker——测试必须用真实 fixture 验证声明而不是合成数据。这一模式在仓库中有直接的真实实现佐证。git filter 的单元测试 src/cmds/git/git.rs 中存在test_filter_log_output_token_savings测试其断言逻辑与文档模式完全一致let savings 100.0 - (count_tokens(output) as f64 / count_tokens(input) as f64 * 100.0); assert!( savings 60.0, Expected ≥60% token savings, got {:.1}%, savings );同文件中还有test_push_filter_token_savings_on_verbose_output同样断言savings 60.0与test_parse_stash_stat_savings针对较温和的场景放宽到 40.0说明节省率红线并非一刀切——不同输出类型可以设定不同的期望阈值。而共享的count_tokens工具函数在真实仓库中定义于 src/core/utils.rs供各 filter 模块的#[cfg(test)]复用。创建真实 fixture的方式是直接捕获真实命令输出# Capture real command output git log -20 tests/fixtures/git_log_raw.txt cargo test tests/fixtures/cargo_test_raw.txt 21 gh pr view 123 tests/fixtures/gh_pr_view_raw.txt # Then test with: # let input include_str!(../tests/fixtures/git_log_raw.txt);仓库的 tests/fixtures/ 目录已经积累了大量此类真实输出 fixture例如mvn_test_fail_slice_raw.txt、gradlew_test_failed_raw.txt、sbt_test_munit_fail.txt、golangci_v2_json.txt、aws_backup_describe_global_settings.json等覆盖 Maven、Gradle、sbt、golangci-lint、AWS 等生态与文档“用真实命令输出做 fixture”的反模式要求相呼应。跨平台 Shell 转义与兼容性测试RTK 需要在 macOSzsh、Linuxbash、WindowsPowerShell上工作而三个平台的 Shell 转义规则不同。文档给出基于#[cfg]条件编译的平台测试模式#[cfg(target_os windows)] const EXPECTED_SHELL: str cmd.exe; #[cfg(target_os macos)] const EXPECTED_SHELL: str zsh; #[cfg(target_os linux)] const EXPECTED_SHELL: str bash; #[test] fn test_shell_escaping() { let cmd r#git log --format%H %s#; let escaped escape_for_shell(cmd); #[cfg(target_os windows)] assert_eq!(escaped, r#git log --format\%H %s\#); #[cfg(not(target_os windows))] assert_eq!(escaped, r#git log --format%H %s#); } #[test] fn test_command_execution_cross_platform() { let result execute_command(git, [--version]); assert!(result.is_ok()); let output result.unwrap(); assert!(output.contains(git version)); // Verify exit code preserved assert_eq!(output.status, 0); }第二个测试还特别验证了退出码保真——RTK 作为代理拦截命令转发被代理命令的退出状态必须原样保留否则上层LLM 或 CI无法判断命令成败。各平台测试手段平台方式macOS本地直接cargo testLinuxdocker run --rm -v $(pwd):/rtk -w /rtk rust:latest cargo testWindows交由 CI/CD或手动如环境可用从源码结构看跨平台关注点也体现在依赖层面Cargo.toml 对 Windows 单独引入了windows-sysWin32_System_Console、Win32_Globalization特性并为所有平台保留了控制台代码页解码依赖encoding_rs/codepage/oem_cp——注释说明映射与增量 UTF-8 走查逻辑在所有平台保持编译并可单测仅代码页查找是 Windows 特有的。这正对应文档反模式中“macOS ≠ Linux ≠ Windows”的三点差异Shell 转义不同、路径分隔符不同、行尾符不同。集成测试执行真实命令的端到端验证集成测试通过 RTK 本身执行真实命令验证端到端行为。典型示例#[test] #[ignore] // Run with: cargo test --ignored fn test_real_git_log() { // Requires: // 1. RTK binary installed (cargo install --path .) // 2. Git repository available let output std::process::Command::new(rtk) .args([git, log, -10]) .output() .expect(Failed to run rtk); assert!(output.status.success(), RTK exited with non-zero status); assert!(!output.stdout.is_empty(), RTK produced empty output); // Verify condensed (not raw git output) let stdout String::from_utf8_lossy(output.stdout); assert!( stdout.len() 5000, Output too large ({} bytes), filter not working, stdout.len() ); // Verify format preservation (spot check) assert!(stdout.contains(commit) || stdout.contains(Author)); }该测试包含三层断言RTK 进程退出码为 0输出非空输出长度小于 5000 字节证明压缩生效而非透传原始 git 输出以及对格式保留的抽查。#[ignore]属性使这类依赖已安装二进制和真实仓库环境的测试不进入常规cargo test而是按需运行。运行方式# Install RTK first cargo install --path . # Run integration tests cargo test --ignored # Specific integration test cargo test --ignored test_real_git_log何时需要写集成测试新增 filter 后验证与真实命令的联动、命令路由变更验证 RTK 正确拦截、hook 集成变更验证 Claude Code hook 重写链路。仓库中#[ignore]集成测试的真实用例可见于 src/main.rs、src/cmds/git/git.rs、src/cmds/jvm/mvn_cmd.rs、src/cmds/system/read.rs 等文件。测试覆盖策略优先级、目标与覆盖率验证优先级目标高优先级——所有 filtergit、cargo、gh、pnpm、docker、lint、tsc 等→ 快照 token 准确性中优先级——边界情况空输出、畸形输入、unicode、ANSI 转义码低优先级——性能基准测试启动时间10ms、内存占用5MB。覆盖目标100% filter 覆盖每个 filter 都有快照测试 token 准确性测试95% token 节省验证使用已知节省率60-90%的 fixture跨平台测试macOS LinuxWindows 仅在 CI。覆盖率验证命令使用 tarpaulin# Install tarpaulin (code coverage tool) cargo install cargo-tarpaulin # Run coverage cargo tarpaulin --out Html --output-dir coverage/ # Open coverage report open coverage/index.html性能红线启动 10ms、内存 5MB与 Cargo.toml 的 release 配置互为因果opt-level 3、lto true、codegen-units 1、panic abort、strip true这些编译期优化正是达成毫秒级启动与低内存占用的基础。常用命令速查# Run all tests cargo test --all # Run snapshot tests only cargo test --test snapshots # Run integration tests (requires real commands rtk installed) cargo test --ignored # Review snapshot changes cargo insta review # Accept all snapshot changes cargo insta accept # Benchmark performance cargo bench # Cross-platform testing (Linux via Docker) docker run --rm -v $(pwd):/rtk -w /rtk rust:latest cargo test此外仓库还提供了聚合脚本 scripts/test-all.sh 等测试编排入口可用于更完整的本地验证。反模式与正确实践反模式禁止不要硬编码输出做测试——必须使用真实命令 fixture先git log -20 tests/fixtures/git_log_raw.txt捕获再include_str!引入不要跳过跨平台测试——Shell 转义、路径分隔符、行尾符三处都存在平台差异至少覆盖 macOS Linux不要忽视性能回归——在 CI 中跑基准启动时间 10ms、内存 5MB可用hyperfine与time -l验证不要接受低于 60% 的 token 节省——这会违背对用户的承诺所有 filter 必须达到 60-90% 节省用真实 fixture 测试节省率下滑时必须在合并前调查并修复。正确实践遵循用insta做快照测试——能捕获非预期输出变化审查与接受变更方便是 Rust 输出验证的标准工具用真实 fixture 验证 token 节省——计算式100.0 - (output_tokens / input_tokens * 100.0)断言savings 60.0在所有平台测试 Shell 转义——使用#[cfg(target_os ...)]编写平台相关断言发布前跑集成测试——先cargo install --path .安装 RTK再cargo test --ignored验证端到端行为。三个完整工作流为新 filter 添加测试场景刚在src/newcmd_cmd.rs实现了filter_newcmd()。创建 fixture真实命令输出newcmd --some-args tests/fixtures/newcmd_raw.txt在src/cmds/ecosystem/newcmd_cmd.rs中添加快照测试#[cfg(test)] mod tests { use super::*; use insta::assert_snapshot; #[test] fn test_newcmd_output_format() { let input include_str!(../tests/fixtures/newcmd_raw.txt); let output filter_newcmd(input); assert_snapshot!(output); } }运行测试生成快照cargo test test_newcmd_output_format审查快照cargo insta review输出正确则按a接受添加 token 准确性测试#[test] fn test_newcmd_token_savings() { let input include_str!(../tests/fixtures/newcmd_raw.txt); let output filter_newcmd(input); let input_tokens count_tokens(input); let output_tokens count_tokens(output); let savings 100.0 - (output_tokens as f64 / input_tokens as f64 * 100.0); assert!(savings 60.0, Expected ≥60% savings, got {:.1}%, savings); }跑全量测试cargo test --all提交git add src/newcmd_cmd.rs tests/fixtures/newcmd_raw.txt src/snapshots/ git commit -m test(newcmd): add snapshot token accuracy tests更新 filter伴随快照测试场景修改了filter_git_log()的输出格式。跑测试预期失败——快照不匹配cargo test test_git_log_output_format审查变更cargo insta review显示新旧快照 diff有意的变更按a接受发现是 bug 则按r拒绝若拒绝修复 filter 逻辑后重跑测试若接受快照已更新提交git add src/snapshots/ git commit -m refactor(git): update log output format发布前跑集成测试# 1. Install RTK locally cargo install --path . --force # 2. Run integration tests cargo test --ignored # 3. Verify output # All tests should pass # If failures: investigate and fix before release测试目录组织文档给出的测试组织蓝图如下rtk/ ├── src/ │ ├── cmds/ │ │ ├── git/ │ │ │ ├── git.rs # Filter implementation │ │ │ │ └── #[cfg(test)] mod tests { ... } # Unit tests │ │ │ └── snapshots/ # Insta snapshots for git module │ │ ├── js/ │ │ ├── python/ │ │ └── ... # Other ecosystems │ ├── core/ │ │ ├── filter.rs # Core filtering with tests │ │ └── snapshots/ │ └── hooks/ ├── tests/ │ ├── common/ │ │ └── mod.rs # Shared test utilities (count_tokens, etc.) │ ├── fixtures/ # Real command output fixtures │ │ ├── git_log_raw.txt │ │ ├── cargo_test_raw.txt │ │ ├── gh_pr_view_raw.txt │ │ └── dotnet/ # Dotnet-specific fixtures │ └── integration_test.rs # Integration tests (#[ignore])最佳实践汇总单元测试内嵌于模块#[cfg(test)] mod testsfixture 存放在tests/fixtures/真实命令输出快照存放在模块对应的snapshots/目录由 insta 自动生成共享工具函数集中管理如count_tokens、辅助函数——在当前仓库中count_tokens实际定义于 src/core/utils.rs各 filter 的#[cfg(test)]模块直接复用效果与独立tests/common/mod.rs等同集成测试放在tests/下并加#[ignore]属性。小结RTK 的测试体系围绕其产品承诺构建快照测试insta保证 filter 输出格式稳定可控token 节省率测试真实 fixture savings 60.0断言守住 60-90% 节省的产品底线跨平台#[cfg]测试处理 zsh/bash/PowerShell 的转义差异#[ignore]集成测试在发布前用真实命令做端到端验证。四类测试层层递进——从输出格式到数值承诺、从单平台到全平台、从单元测试到端到端——共同构成一个 CLI 代理在“压缩输出不能破坏语义与退出码”约束下的完整质量护栏。【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
rtk 测试专项指南：快照测试、Token 节省量化验证与跨平台 Shell 兼容性测试
rtk 测试专项指南快照测试、Token 节省量化验证与跨平台 Shell 兼容性测试【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk本文基于 RTK 仓库中的测试专项 Agent 定义文档 rtk-testing-specialist.md系统讲解 RTK一个将常见开发命令输出压缩 60-90% token 消耗的 Rust CLI 代理特有的四类测试体系基于insta的输出快照测试、以真实 fixture 量化 token 节省率的准确性验证、跨平台macOS/zsh、Linux/bash、Windows/PowerShellShell 转义测试以及执行真实命令的集成测试。读完后你将掌握为新 filter 编写完整测试的标准工作流、cargo insta快照审查流程以及如何在 CI 中守住“60% 节省率发布红线”。测试专项 Agent 的定位与核心职责RTK 在.claude/agents/目录下为 Claude Code 定义了多个子代理其中 rtk-testing-specialist.md 专门面向 RTK 的独特测试需求命令输出验证、token 计数准确性、跨平台 Shell 兼容性。该 Agent 的 frontmatter 声明如下--- name: rtk-testing-specialist description: RTK testing expert - snapshot tests, token accuracy, cross-platform validation model: sonnet tools: Read, Write, Edit, Bash, Grep, Glob ---五大核心职责快照测试Snapshot testing使用instacrate 做输出验证Token 准确性Token accuracy用真实 fixture 验证 60-90% 的节省声明跨平台Cross-platform测试 bash/zsh/PowerShell 兼容性回归防护Regression prevention在 CI 中检测性能退化集成测试Integration tests执行真实命令git、cargo、gh、pnpm 等。从源码结构看这套职责与仓库实际布局高度对应各生态命令 filter 位于 src/cmds/ 下git、cargo、gh、js、python 等约 9 个生态共享工具函数如count_tokens位于 src/core/utils.rs真实命令输出 fixture 集中在 tests/fixtures/而 tests/ 根目录下的guard_integration_test.rs、pipeline_stdin_test.rs、copilot_selfheal_test.rs等则是跨模块的集成测试。快照测试模式以insta为主力策略文档明确insta快照测试是 filter 输出的首要测试策略。其基本用法是use insta::assert_snapshot; #[test] fn test_git_log_output() { let input include_str!(../tests/fixtures/git_log_raw.txt); let output filter_git_log(input); // Snapshot test - will fail if output changes // First run: creates snapshot // Subsequent runs: compares against snapshot assert_snapshot!(output); }工作机制是首次运行创建快照基线后续每次运行都将当前输出与快照比对输出格式一旦发生变化无论有意还是意外测试即失败从而捕获对 LLM 上下文格式的非预期改动。标准工作流四步写测试在测试中加入assert_snapshot!(output);跑测试cargo test首次运行会创建新快照审查快照cargo insta review交互式审查接受变更确认输出正确后执行cargo insta accept。适用时机所有新 filter——每个 filter 至少应有一个快照测试输出格式变更——修改 filter 逻辑时回归检测——捕获非预期的输出变化。一个完整的“从零添加快照测试”操作示例# 1. Create fixture echo raw command output tests/fixtures/newcmd_raw.txt # 2. Write test cat src/newcmd_cmd.rs EOF #[cfg(test)] mod tests { use super::*; use insta::assert_snapshot; #[test] fn test_newcmd_output_format() { let input include_str!(../tests/fixtures/newcmd_raw.txt); let output filter_newcmd(input); assert_snapshot!(output); } } EOF # 3. Run test (creates snapshot) cargo test test_newcmd_output_format # 4. Review snapshot cargo insta review # Press a to accept, r to reject # 5. Snapshot saved in snapshots/ ls -la src/snapshots/需要说明的是快照文件按模块就近存放如 git 模块的快照放在src/cmds/git/snapshots/这与下文“测试组织”一节一致。仓库贡献规范 CONTRIBUTING.md 也印证了这一测试分层单元测试内嵌模块#[cfg(test)]、快照测试由 filter 模块创建、集成测试通过#[ignore]标记并以cargo test --ignored单独运行。Token 节省率量化验证60-90% 承诺的测试护栏RTK 的核心产品承诺是 60-90% 的 token 节省因此文档要求所有 filter 必须在测试中量化验证节省率#[cfg(test)] mod tests { use super::*; // Helper function (add to tests/common/mod.rs if not exists) fn count_tokens(text: str) - usize { // Simple whitespace tokenization (good enough for tests) text.split_whitespace().count() } #[test] fn test_token_savings_claim() { let fixtures [ (git_log, 0.80), // 80% savings expected (cargo_test, 0.90), // 90% savings expected (gh_pr_view, 0.87), // 87% savings expected ]; for (name, expected_savings) in fixtures { let input include_str!(format!(../tests/fixtures/{}_raw.txt, name)); let output apply_filter(name, input); let input_tokens count_tokens(input); let output_tokens count_tokens(output); let savings 100.0 - (output_tokens as f64 / input_tokens as f64 * 100.0); assert!( savings expected_savings, {} filter: expected ≥{:.0}% savings, got {:.1}%, name, expected_savings * 100.0, savings * 100.0 ); } } }关键公式为savings 100.0 - (output_tokens / input_tokens * 100.0)其中 token 采用简单的空白分词split_whitespace().count()即可满足测试精度需求。文档强调如果节省率跌破 60%这是发布阻断项release blocker——测试必须用真实 fixture 验证声明而不是合成数据。这一模式在仓库中有直接的真实实现佐证。git filter 的单元测试 src/cmds/git/git.rs 中存在test_filter_log_output_token_savings测试其断言逻辑与文档模式完全一致let savings 100.0 - (count_tokens(output) as f64 / count_tokens(input) as f64 * 100.0); assert!( savings 60.0, Expected ≥60% token savings, got {:.1}%, savings );同文件中还有test_push_filter_token_savings_on_verbose_output同样断言savings 60.0与test_parse_stash_stat_savings针对较温和的场景放宽到 40.0说明节省率红线并非一刀切——不同输出类型可以设定不同的期望阈值。而共享的count_tokens工具函数在真实仓库中定义于 src/core/utils.rs供各 filter 模块的#[cfg(test)]复用。创建真实 fixture的方式是直接捕获真实命令输出# Capture real command output git log -20 tests/fixtures/git_log_raw.txt cargo test tests/fixtures/cargo_test_raw.txt 21 gh pr view 123 tests/fixtures/gh_pr_view_raw.txt # Then test with: # let input include_str!(../tests/fixtures/git_log_raw.txt);仓库的 tests/fixtures/ 目录已经积累了大量此类真实输出 fixture例如mvn_test_fail_slice_raw.txt、gradlew_test_failed_raw.txt、sbt_test_munit_fail.txt、golangci_v2_json.txt、aws_backup_describe_global_settings.json等覆盖 Maven、Gradle、sbt、golangci-lint、AWS 等生态与文档“用真实命令输出做 fixture”的反模式要求相呼应。跨平台 Shell 转义与兼容性测试RTK 需要在 macOSzsh、Linuxbash、WindowsPowerShell上工作而三个平台的 Shell 转义规则不同。文档给出基于#[cfg]条件编译的平台测试模式#[cfg(target_os windows)] const EXPECTED_SHELL: str cmd.exe; #[cfg(target_os macos)] const EXPECTED_SHELL: str zsh; #[cfg(target_os linux)] const EXPECTED_SHELL: str bash; #[test] fn test_shell_escaping() { let cmd r#git log --format%H %s#; let escaped escape_for_shell(cmd); #[cfg(target_os windows)] assert_eq!(escaped, r#git log --format\%H %s\#); #[cfg(not(target_os windows))] assert_eq!(escaped, r#git log --format%H %s#); } #[test] fn test_command_execution_cross_platform() { let result execute_command(git, [--version]); assert!(result.is_ok()); let output result.unwrap(); assert!(output.contains(git version)); // Verify exit code preserved assert_eq!(output.status, 0); }第二个测试还特别验证了退出码保真——RTK 作为代理拦截命令转发被代理命令的退出状态必须原样保留否则上层LLM 或 CI无法判断命令成败。各平台测试手段平台方式macOS本地直接cargo testLinuxdocker run --rm -v $(pwd):/rtk -w /rtk rust:latest cargo testWindows交由 CI/CD或手动如环境可用从源码结构看跨平台关注点也体现在依赖层面Cargo.toml 对 Windows 单独引入了windows-sysWin32_System_Console、Win32_Globalization特性并为所有平台保留了控制台代码页解码依赖encoding_rs/codepage/oem_cp——注释说明映射与增量 UTF-8 走查逻辑在所有平台保持编译并可单测仅代码页查找是 Windows 特有的。这正对应文档反模式中“macOS ≠ Linux ≠ Windows”的三点差异Shell 转义不同、路径分隔符不同、行尾符不同。集成测试执行真实命令的端到端验证集成测试通过 RTK 本身执行真实命令验证端到端行为。典型示例#[test] #[ignore] // Run with: cargo test --ignored fn test_real_git_log() { // Requires: // 1. RTK binary installed (cargo install --path .) // 2. Git repository available let output std::process::Command::new(rtk) .args([git, log, -10]) .output() .expect(Failed to run rtk); assert!(output.status.success(), RTK exited with non-zero status); assert!(!output.stdout.is_empty(), RTK produced empty output); // Verify condensed (not raw git output) let stdout String::from_utf8_lossy(output.stdout); assert!( stdout.len() 5000, Output too large ({} bytes), filter not working, stdout.len() ); // Verify format preservation (spot check) assert!(stdout.contains(commit) || stdout.contains(Author)); }该测试包含三层断言RTK 进程退出码为 0输出非空输出长度小于 5000 字节证明压缩生效而非透传原始 git 输出以及对格式保留的抽查。#[ignore]属性使这类依赖已安装二进制和真实仓库环境的测试不进入常规cargo test而是按需运行。运行方式# Install RTK first cargo install --path . # Run integration tests cargo test --ignored # Specific integration test cargo test --ignored test_real_git_log何时需要写集成测试新增 filter 后验证与真实命令的联动、命令路由变更验证 RTK 正确拦截、hook 集成变更验证 Claude Code hook 重写链路。仓库中#[ignore]集成测试的真实用例可见于 src/main.rs、src/cmds/git/git.rs、src/cmds/jvm/mvn_cmd.rs、src/cmds/system/read.rs 等文件。测试覆盖策略优先级、目标与覆盖率验证优先级目标高优先级——所有 filtergit、cargo、gh、pnpm、docker、lint、tsc 等→ 快照 token 准确性中优先级——边界情况空输出、畸形输入、unicode、ANSI 转义码低优先级——性能基准测试启动时间10ms、内存占用5MB。覆盖目标100% filter 覆盖每个 filter 都有快照测试 token 准确性测试95% token 节省验证使用已知节省率60-90%的 fixture跨平台测试macOS LinuxWindows 仅在 CI。覆盖率验证命令使用 tarpaulin# Install tarpaulin (code coverage tool) cargo install cargo-tarpaulin # Run coverage cargo tarpaulin --out Html --output-dir coverage/ # Open coverage report open coverage/index.html性能红线启动 10ms、内存 5MB与 Cargo.toml 的 release 配置互为因果opt-level 3、lto true、codegen-units 1、panic abort、strip true这些编译期优化正是达成毫秒级启动与低内存占用的基础。常用命令速查# Run all tests cargo test --all # Run snapshot tests only cargo test --test snapshots # Run integration tests (requires real commands rtk installed) cargo test --ignored # Review snapshot changes cargo insta review # Accept all snapshot changes cargo insta accept # Benchmark performance cargo bench # Cross-platform testing (Linux via Docker) docker run --rm -v $(pwd):/rtk -w /rtk rust:latest cargo test此外仓库还提供了聚合脚本 scripts/test-all.sh 等测试编排入口可用于更完整的本地验证。反模式与正确实践反模式禁止不要硬编码输出做测试——必须使用真实命令 fixture先git log -20 tests/fixtures/git_log_raw.txt捕获再include_str!引入不要跳过跨平台测试——Shell 转义、路径分隔符、行尾符三处都存在平台差异至少覆盖 macOS Linux不要忽视性能回归——在 CI 中跑基准启动时间 10ms、内存 5MB可用hyperfine与time -l验证不要接受低于 60% 的 token 节省——这会违背对用户的承诺所有 filter 必须达到 60-90% 节省用真实 fixture 测试节省率下滑时必须在合并前调查并修复。正确实践遵循用insta做快照测试——能捕获非预期输出变化审查与接受变更方便是 Rust 输出验证的标准工具用真实 fixture 验证 token 节省——计算式100.0 - (output_tokens / input_tokens * 100.0)断言savings 60.0在所有平台测试 Shell 转义——使用#[cfg(target_os ...)]编写平台相关断言发布前跑集成测试——先cargo install --path .安装 RTK再cargo test --ignored验证端到端行为。三个完整工作流为新 filter 添加测试场景刚在src/newcmd_cmd.rs实现了filter_newcmd()。创建 fixture真实命令输出newcmd --some-args tests/fixtures/newcmd_raw.txt在src/cmds/ecosystem/newcmd_cmd.rs中添加快照测试#[cfg(test)] mod tests { use super::*; use insta::assert_snapshot; #[test] fn test_newcmd_output_format() { let input include_str!(../tests/fixtures/newcmd_raw.txt); let output filter_newcmd(input); assert_snapshot!(output); } }运行测试生成快照cargo test test_newcmd_output_format审查快照cargo insta review输出正确则按a接受添加 token 准确性测试#[test] fn test_newcmd_token_savings() { let input include_str!(../tests/fixtures/newcmd_raw.txt); let output filter_newcmd(input); let input_tokens count_tokens(input); let output_tokens count_tokens(output); let savings 100.0 - (output_tokens as f64 / input_tokens as f64 * 100.0); assert!(savings 60.0, Expected ≥60% savings, got {:.1}%, savings); }跑全量测试cargo test --all提交git add src/newcmd_cmd.rs tests/fixtures/newcmd_raw.txt src/snapshots/ git commit -m test(newcmd): add snapshot token accuracy tests更新 filter伴随快照测试场景修改了filter_git_log()的输出格式。跑测试预期失败——快照不匹配cargo test test_git_log_output_format审查变更cargo insta review显示新旧快照 diff有意的变更按a接受发现是 bug 则按r拒绝若拒绝修复 filter 逻辑后重跑测试若接受快照已更新提交git add src/snapshots/ git commit -m refactor(git): update log output format发布前跑集成测试# 1. Install RTK locally cargo install --path . --force # 2. Run integration tests cargo test --ignored # 3. Verify output # All tests should pass # If failures: investigate and fix before release测试目录组织文档给出的测试组织蓝图如下rtk/ ├── src/ │ ├── cmds/ │ │ ├── git/ │ │ │ ├── git.rs # Filter implementation │ │ │ │ └── #[cfg(test)] mod tests { ... } # Unit tests │ │ │ └── snapshots/ # Insta snapshots for git module │ │ ├── js/ │ │ ├── python/ │ │ └── ... # Other ecosystems │ ├── core/ │ │ ├── filter.rs # Core filtering with tests │ │ └── snapshots/ │ └── hooks/ ├── tests/ │ ├── common/ │ │ └── mod.rs # Shared test utilities (count_tokens, etc.) │ ├── fixtures/ # Real command output fixtures │ │ ├── git_log_raw.txt │ │ ├── cargo_test_raw.txt │ │ ├── gh_pr_view_raw.txt │ │ └── dotnet/ # Dotnet-specific fixtures │ └── integration_test.rs # Integration tests (#[ignore])最佳实践汇总单元测试内嵌于模块#[cfg(test)] mod testsfixture 存放在tests/fixtures/真实命令输出快照存放在模块对应的snapshots/目录由 insta 自动生成共享工具函数集中管理如count_tokens、辅助函数——在当前仓库中count_tokens实际定义于 src/core/utils.rs各 filter 的#[cfg(test)]模块直接复用效果与独立tests/common/mod.rs等同集成测试放在tests/下并加#[ignore]属性。小结RTK 的测试体系围绕其产品承诺构建快照测试insta保证 filter 输出格式稳定可控token 节省率测试真实 fixture savings 60.0断言守住 60-90% 节省的产品底线跨平台#[cfg]测试处理 zsh/bash/PowerShell 的转义差异#[ignore]集成测试在发布前用真实命令做端到端验证。四类测试层层递进——从输出格式到数值承诺、从单平台到全平台、从单元测试到端到端——共同构成一个 CLI 代理在“压缩输出不能破坏语义与退出码”约束下的完整质量护栏。【免费下载链接】rtkCLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies项目地址: https://gitcode.com/GitHub_Trending/rtk4/rtk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考