在 CentOS 上把 Rust 单元测试跑通，核心并不在“测试命令有多复杂”，而在于先把工具链、环境变量和项目结构准备到位。下面按实际操作顺序整理一遍，从安装 Rust 到看到测试结果，读者可以据此快速判断自己卡在哪一步，以及 `cargo test` 背后到底做了什么。
安装 Rust 工具链
如果机器上还没有 Rust，第一步先安装官方工具链。常见做法是直接使用 rustup 提供的安装脚本：
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh这条命令会下载并执行 Rust 的安装脚本，随后按提示完成安装即可。对于大多数 CentOS 环境来说，这一步就是后续运行 cargo、编译代码和执行测试的前提。
加载环境并确认 cargo 可用
安装完成后，还需要让当前 shell 识别 Rust 的命令行工具。通常做法是重新加载 cargo 环境配置：
source $HOME/.cargo/env这一步不能省略。否则即便 Rust 已经装好，终端里也可能还找不到 cargo 命令，接下来的建项目和跑测试都会中断。对刚装完工具链的环境来说，先执行一次这条命令，能避免不少无谓排查。
创建测试项目骨架
如果手头还没有现成的 Rust 项目，可以先用 cargo 创建一个最基础的工程，再在这个工程里写测试：
cargo new my_project
cd my_projectcargo new my_project 会生成一个名为 my_project 的项目目录，并准备好基础文件结构。进入项目目录后，就可以开始补充业务代码和对应测试。
这一步的意义不只是“生成一个文件夹”，更重要的是建立 Rust 默认认可的项目布局。后面执行 cargo test 时，Cargo 会基于这套结构去编译和发现测试代码。
在代码中编写单元测试
Rust 的单元测试通常直接写在被测代码所在文件中，并放在 #[cfg(test)] 模块里。下面是一个最基础的示例：
// lib.rs
pub fn add(a: i32, b: i32) -> i32 {
a + b
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn test_add() {
assert_eq!(add(2, 2), 4);
}
}这里有几个关键信息：
`#[cfg(test)]` 的作用
这个模块只会在测试场景下参与编译，不会作为正常发布代码的一部分始终启用。这样既方便把测试和实现写在一起，也不会影响常规构建。
`#[test]` 如何标记测试函数
带有 #[test] 标记的函数会被测试框架识别出来，cargo test 执行时会自动收集并运行这些函数。
`assert_eq!` 用来校验结果
示例中的 assert_eq!(add(2, 2), 4) 表示把函数返回值和预期值进行比较。如果两边一致，测试通过；如果不一致，Cargo 会输出详细失败信息，帮助定位问题。
使用 cargo test 执行测试
测试写好后，回到项目根目录直接运行：
cargo test这条命令会完成几件事：先编译项目，再收集所有带有 #[test] 标记的测试函数，最后逐个执行并输出结果。也就是说，它不是单纯“跑一下脚本”，而是把编译、发现测试和执行测试串成了一次完整流程。
如何理解测试输出结果
如果流程正常，终端里通常会看到类似下面的输出：
running 1 test
test tests::test_add ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out这段输出可以直接用来判断测试状态：
running 1 test表示本次共执行了 1 个测试。test tests::test_add ... ok表示名为tests::test_add的测试已经通过。1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out则是本次执行的汇总结果。
如果没有看到 ok，而是出现失败信息，也不用急着重装环境。多数情况下，Cargo 给出的报错已经足够定位是断言不成立、函数逻辑错误，还是测试代码本身写得不符合预期。
对刚开始在 CentOS 上使用 Rust 的读者来说，先把这条最基础的单元测试链路跑通，比一开始就堆很多复杂用例更重要。等基础流程稳定后，再去补边界条件、异常输入和更多断言，测试的价值才会逐步体现出来。
