工具链测试要覆盖构建和发布边界工作区里单个 crate 的单测通过不代表命令行真的能启动。我会在临时目录执行一次二进制并检查退出码和输出格式cargo run -p cli -- --help涉及文件时只创建临时样例断言工具不会写到预期目录之外。集成测试慢一些但能抓到 feature 组合和参数解析的问题。它仍不能代替真实平台测试特别是路径和权限差异。单元测试只看到源码的一部分库函数通过测试仍可能在二进制入口、配置加载或依赖组合处失败。命令行程序还有参数解析、当前目录、环境变量、标准输入输出和退出码等契约。它们不一定属于某个核心函数却直接决定用户能否运行工具因此需要从实际入口验证。工作区项目还要检查包之间的关系。某个 crate 使用默认 feature 能编译不代表关闭默认项或启用可选后端时仍成立。测试矩阵不必穷举所有组合但应覆盖文档明确支持的配置。没有承诺支持的组合要写清楚避免用户把一次偶然构建成功当成兼容保证。在干净环境中重新构建开发机常留有旧产物、全局工具和本地配置容易掩盖缺失依赖。构建测试应从干净目录开始使用锁定的工具链和依赖确认生成物不依赖工作区外的文件。若构建脚本读取环境变量或调用外部程序应在文档与检查中显式列出。生成代码、资源打包和版本信息也属于构建结果。只检查编译退出码可能漏掉空资源、错误路径或未更新的元数据。可以对产物结构做有限断言并实际启动二进制完成最小操作。测试样例用虚构内容凭据和用户目录不进入构建日志。命令行测试要观察副作用正常参数、缺失参数、未知选项和互斥参数都应有稳定行为。错误信息应指出问题所在退出码供脚本判断帮助文本则与实际选项保持一致。程序接收路径时要测试不存在、只读、包含空格和指向允许范围之外的情况。临时目录中的集成测试不仅核对输出还要比较执行前后的文件。工具应该创建哪些产物失败后是否留下半文件重复运行会覆盖、跳过还是报错都应由接口约定。涉及删除或远端调用的命令可提供预演模式测试默认状态不会产生不可逆副作用。发布边界从制品开始本地cargo run使用的是工作区源码用户拿到的却是打包后的制品。发布前应从最终包或二进制重新安装并运行确认动态库、资源文件、许可证和版本信息完整。压缩包解开后的目录结构、安装脚本和卸载行为也需要最小验证。制品来源要可追溯到提交与构建环境。依赖解析结果、工具链版本和校验信息与发布记录关联出现问题时才能确认受影响版本。发布测试不使用真实仓库令牌上传动作先在隔离位置演练正式发布仍由有权限的人确认。平台差异不能靠推断路径分隔、文件权限、换行、终端编码和信号处理在不同平台上会表现不同。条件编译能让代码通过编译却不能证明运行行为一致。项目承诺支持的平台应至少执行一次实际二进制测试无法覆盖的环境则在发布说明中如实列出。失败报告保留平台、工具链、feature、命令和脱敏输出方便重放。修复后先运行原失败场景再检查相邻发布步骤。工具链测试真正要守住的是源码到用户手中这段距离只有最终制品能安装、启动、正确失败并且可追溯单元测试的绿色结果才算完成了交付。