很多刚接触 Rust 的开发者会把“写单元测试”想得很复杂，尤其是在 Debian 这类常见开发环境里，总担心工具链、项目结构和测试入口不够清晰。其实这件事可以拆成几步固定动作：先把 Rust 装好，再用 Cargo 建立项目，然后把测试写进合适的位置，最后通过命令执行和排查结果；照着这条线走，你就能判断自己的测试是否真正跑起来了。
先把 Debian 上的 Rust 工具链准备好
在 Debian 上为 Rust 项目写测试，前提是先把 Rust 工具链装完整。最常见的安装方式是直接使用 rustup：
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh这条命令会安装 Rust 及其工具链管理器。安装完成后，系统通常会自动把相关路径加入 PATH，这样后续就能直接使用 cargo、rustc 等命令。如果你后面执行命令时找不到 Rust 工具，优先检查的就是这一步是否已经生效。
没有现成工程时，先用 Cargo 建一个项目
如果你手里还没有 Rust 项目，最快的起点就是用 cargo 创建一个新工程：
cargo new my_project
cd my_projectcargo 既是 Rust 的包管理器，也是构建系统。执行完以后，项目目录、基础源码和配置文件都会自动生成，你不需要手动搭结构。对刚开始练习单元测试的人来说，这种标准工程最省事，也最方便直接运行测试命令。
单元测试应该写在哪里，最基本的写法是什么
Rust 项目的业务代码通常写在 src/lib.rs 或 src/main.rs 中。测试代码既可以放在同一个文件末尾，也可以放进单独的 tests 目录里。入门阶段最常见的方式，是在源文件内使用 #[cfg(test)] 包住测试模块，让这部分代码只在测试模式下参与编译。
下面是一个最基础的例子，在 src/lib.rs 里定义加法函数，并附带一个测试：
// src/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]用来声明这是一个测试用例。assert_eq!用于校验“实际结果”和“期望结果”是否一致。
如果你的目标只是先把 Debian 上的 Rust 单元测试跑通，这个结构已经够用了。等后续项目复杂起来，再考虑把不同测试拆到更细的文件和目录中。
如何运行测试，以及终端输出代表什么
测试写好后，直接在项目根目录执行下面的命令即可：
cargo test这个命令会自动完成编译，并运行所有带有 #[test] 标记的测试函数。对于大多数小型项目来说，它就是最核心、也最常用的测试入口。
cargo test 的输出通常比较直观：通过的测试会显示成功状态，失败的测试则会给出更具体的信息，包括哪个断言失败了、期望值和实际值分别是什么，有时还会附带失败位置的上下文。这些信息足够帮助你快速判断问题出在函数逻辑、参数处理，还是测试预期本身写错了。
测试失败后怎么排查，以及为什么要接入 CI
当测试没有通过时，最直接的排查办法是在测试函数里加入 println! 输出中间变量，或者使用 dbg! 宏快速查看表达式结果。对于刚开始接触 Rust 测试的人来说，这种方式比一上来接调试器更直接，也更容易缩小问题范围。
如果你使用的是带调试能力的 IDE，也可以结合 IDE 的断点功能进一步查看执行路径。但无论采用哪种方式，目标都一样：先确认函数结果为什么和断言预期不一致，再决定是改代码还是改测试。
另外，手动执行测试只适合个人练习或很小的项目。只要项目开始多人协作，最好尽早把测试放进持续集成流程。常见选择包括 GitHub Actions、GitLab CI/CD 和 Travis CI，这些平台对 Rust 项目都有较成熟的支持。配置完成后，每次提交或推送代码都能自动运行测试，比依赖人工记得执行 cargo test 更稳妥。
从实际使用角度看，在 Debian 上为 Rust 项目编写单元测试并没有额外门槛，关键只是把流程固定下来：工具链可用、项目结构标准、测试入口清晰、失败时能快速定位。把这几件事做顺，后面无论是写库还是写应用，测试都会成为日常开发的一部分。
