测试越多越好吗？用 cargo-test-prune 按变异证据精简 Rust 测试
AI 编程工具让补测试变得容易，真正棘手的往往是：一套测试里，哪些测试提供了重复的回归保护？Rust 工具 cargo-test-prune 尝试把这个问题转成可检查的实验：它借助变异测试观察哪些测试能发现哪些人为注入的缺陷，再提出一个保留相同已观察检测能力的精简方案。
这里的关键词是“提出”，不是自动证明某个测试毫无价值。工具测到的是有限变异样本上的检测关系；需求表达、边界条件以及尚未覆盖的缺陷类型仍需要开发者判断。
从变异测试得到证据
变异测试会对程序做小幅改动，例如把比较符号 > 0 改成 >= 0，然后运行测试。如果某项测试因此失败，就说明它捕获了这个变异。cargo-test-prune 基于这些观测，寻找一组测试，让保留下来的测试合计仍能检测到原先观察到的变异。
项目 README 给出的示例中，工具发现六个测试（其中一个被忽略）和五个变异，建议在保留两个活动测试的同时删去三个测试；两个保留测试合计覆盖五个变异。示例特别指出，zero 测试独自捕获了 > 0 变成 >= 0 的变化，因此被保留。这个结果只说明该样本上的检测覆盖，不代表其余测试对规格说明或未来变更没有价值。
安装与运行
项目 README 要求使用当前稳定版 Rust 工具链，并先安装 cargo-mutants：
cargo install cargo-mutants --locked cargo install cargo-test-prune --locked # 在待分析的项目中运行 cargo test-prune analyze
默认分析范围是整个 workspace，即使命令从某个成员 crate 目录执行也是如此。若只想分析某个包，可用 -p 限定；变异数量也可以显式设置：
cargo test-prune analyze -p parser --max-mutants 100 cargo test-prune analyze --manifest-path ../parser/Cargo.toml --features serde
README 说明默认按生成顺序分析前 50 个变异，并在报告中显示选中数量和总数。因此这是一项有边界的实验，不是随机抽样，也不应把默认结果误读为整个程序缺陷空间的统计结论。
先审报告，再决定是否删测试
工具提供 --keep 将重要测试固定在方案中，模式会按测试完整身份的子串匹配；报告也可以在不重新构建、运行测试的情况下重新计算：
cargo test-prune analyze --keep negative --keep backward_compatibility cargo test-prune report test-prune.json --keep negative cargo test-prune report test-prune.json --weight time
report 的新提案只用于展示，不会覆盖已保存的 JSON；重新查看时需要再次传入固定项。默认权重对每个测试一视同仁，--weight time 则使用基线运行时间，但其中包含 Cargo 启动开销，结果可能变化。工具采用贪心集合覆盖并做冗余移除和局部替换搜索，README 明确说明不保证全局最优。
建议把它接入维护流程而非直接当清理脚本：先保存报告，检查候选测试是否承载了重要规格或稀有边界，再在临时副本中验证删减后的测试集。项目提供的 --apply 会删除提案中的测试，因此应先审阅变更、确认代码已备份，并通过完整测试和代码审查后再应用。对于覆盖不足、测试含义不清或关键行为难以用现有变异表达的模块，保留冗余测试通常比追求数字更稳妥。
适用范围与边界
这类工具适合测试运行成本高、测试集合逐渐膨胀，且团队希望获得可复核删减依据的 Rust workspace。它不替代测试设计：变异算子有限、样本数量有限，观测到的“同等覆盖”不等于对所有输入和未来需求等价。更稳妥的用法是把报告当作代码审查线索，明确固定关键测试，并在隔离副本中验证结果；不要只因某测试当前未杀死变异，就断言它没有价值。
相关链接