测试组织
正如本章开头所述，测试是一门复杂的学问，不同的人使用不同的术语和组织方式。Rust 社区将测试分为两大主要类别：单元测试（unit tests）和集成测试（integration tests）。单元测试小巧且更专注，一次测试一个独立的模块，并且可以测试私有接口。集成测试完全独立于你的库，并以其他外部代码相同的方式使用你的代码，仅使用公共接口，并且可能在每个测试中执行多个模块。
编写这两种类型的测试很重要，可以确保你的库的各个部分都能按预期工作，无论是独立工作还是协同工作。
单元测试
单元测试的目的是独立于其他代码测试代码的每个单元，以快速找出代码哪里工作正常哪里不正常。你会将单元测试放在 src 目录中与它们要测试的代码在同一个文件中。约定是在每个文件中创建一个名为 tests 的模块来包含测试函数，并使用 cfg(test) 标注这个模块。
tests 模块和 #[cfg(test)]
tests 模块上的 #[cfg(test)] 标注告诉 Rust 只在你运行 cargo test 时才编译和运行测试代码，而不是在你运行 cargo build 时。这在你只想构建库时节省了编译时间，并节省了生成的编译产物（artifact）的空间，因为测试代码不包含在内。你会看到，因为集成测试位于不同的目录中，它们不需要 #[cfg(test)] 标注。然而，由于单元测试与代码位于同一文件中，你会使用 #[cfg(test)] 来指定它们不应该包含在编译结果中。
回想一下，当我们在本章第一节生成新的 adder 项目时，Cargo 为我们生成了这些代码
文件名: src/lib.rs
pub fn add(left: u64, right: u64) -> u64 {
left + right
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn it_works() {
let result = add(2, 2);
assert_eq!(result, 4);
}
}在自动生成的 tests 模块上，属性 cfg 代表 configuration（配置），并告诉 Rust 只有在给定某个配置选项时才包含后面的项。在本例中，配置选项是 test，这是 Rust 为编译和运行测试提供的。通过使用 cfg 属性，Cargo 只在我们主动运行 cargo test 时才会编译测试代码。这包括此模块中可能存在的任何辅助函数，除了用 #[test] 标注的函数之外。
测试私有函数
测试社区内部对于是否应该直接测试私有函数存在争议，其他语言也使得测试私有函数变得困难或不可能。无论你遵循哪种测试理念，Rust 的隐私规则确实允许你测试私有函数。考虑一下 Listing 11-12 中的代码，其中包含私有函数 internal_adder。
pub fn add_two(a: usize) -> usize {
internal_adder(a, 2)
}
fn internal_adder(left: usize, right: usize) -> usize {
left + right
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn internal() {
let result = internal_adder(2, 2);
assert_eq!(result, 4);
}
}注意，internal_adder 函数没有标记为 pub。测试只是 Rust 代码，tests 模块也只是另一个模块。正如我们在 “引用模块树中的项的路径” 中讨论的那样，子模块中的项可以使用其祖先模块中的项。在这个测试中，我们使用 use super::* 将 tests 模块父级的所有项引入作用域，然后测试就可以调用 internal_adder 了。如果你认为不应该测试私有函数，Rust 中也没有任何东西会强迫你这样做。
集成测试
在 Rust 中，集成测试完全独立于你的库。它们使用你的库的方式与任何其他代码相同，这意味着它们只能调用属于你的库的公共 API 的函数。它们的目的是测试你的库的许多部分是否协同工作正常。独立工作正常的代码单元在集成时可能会出现问题，因此，集成代码的测试覆盖率也很重要。要创建集成测试，你首先需要一个 tests 目录。
tests 目录
我们在项目目录的顶层创建一个 tests 目录，与 src 目录并排。Cargo 知道在这个目录中查找集成测试文件。然后我们可以创建任意数量的测试文件，Cargo 会将每个文件编译成一个独立的 crate。
让我们来创建一个集成测试。假设 Listing 11-12 中的代码仍在 src/lib.rs 文件中，创建一个 tests 目录，并创建一个名为 tests/integration_test.rs 的新文件。你的目录结构应该像这样
adder
├── Cargo.lock
├── Cargo.toml
├── src
│ └── lib.rs
└── tests
└── integration_test.rs
将 Listing 11-13 中的代码输入到 tests/integration_test.rs 文件中。
use adder::add_two;
#[test]
fn it_adds_two() {
let result = add_two(2);
assert_eq!(result, 4);
}adder crate 中一个函数的集成测试tests 目录中的每个文件都是一个独立的 crate，因此我们需要将我们的库引入到每个测试 crate 的作用域中。出于这个原因，我们在代码顶部添加了 use adder::add_two;，这在单元测试中是不需要的。
我们不需要用 #[cfg(test)] 标注 tests/integration_test.rs 中的任何代码。Cargo 会特殊处理 tests 目录，只在我们运行 cargo test 时编译此目录中的文件。现在运行 cargo test
$ cargo test
Compiling adder v0.1.0 (file:///projects/adder)
Finished `test` profile [unoptimized + debuginfo] target(s) in 1.31s
Running unittests src/lib.rs (target/debug/deps/adder-1082c4b063a8fbe6)
running 1 test
test tests::internal ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
Running tests/integration_test.rs (target/debug/deps/integration_test-1082c4b063a8fbe6)
running 1 test
test it_adds_two ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
Doc-tests adder
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
输出的三个部分包括单元测试、集成测试和文档测试（doc tests）。注意，如果某个部分中的任何测试失败，后面的部分将不会运行。例如，如果一个单元测试失败，就不会有集成测试和文档测试的输出，因为只有在所有单元测试都通过的情况下，这些测试才会运行。
单元测试的第一部分与我们之前看到的相同：每个单元测试一行（其中一个是我们根据 Listing 11-12 添加的名为 internal 的测试），然后是一行单元测试的摘要。
集成测试部分以 Running tests/integration_test.rs 这行开头。接下来，该集成测试中的每个测试函数都有一行，以及一行集成测试结果的摘要，就在 Doc-tests adder 部分开始之前。
每个集成测试文件都有自己的部分，因此，如果我们向 tests 目录添加更多文件，就会有更多的集成测试部分。
我们仍然可以通过将测试函数名称作为参数传递给 cargo test 来运行特定的集成测试函数。要运行特定集成测试文件中的所有测试，请使用 cargo test 的 --test 参数，后跟文件名
$ cargo test --test integration_test
Compiling adder v0.1.0 (file:///projects/adder)
Finished `test` profile [unoptimized + debuginfo] target(s) in 0.64s
Running tests/integration_test.rs (target/debug/deps/integration_test-82e7799c1bc62298)
running 1 test
test it_adds_two ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
此命令只运行 tests/integration_test.rs 文件中的测试。
集成测试中的子模块
随着你添加更多集成测试，你可能希望在 tests 目录中创建更多文件来帮助组织它们；例如，可以根据它们正在测试的功能对测试函数进行分组。如前所述，tests 目录中的每个文件都编译成一个独立的 crate，这有助于创建独立的作用域，以更贴切地模拟最终用户使用你的 crate 的方式。然而，这意味着 tests 目录中的文件与 src 目录中的文件行为不同，正如你在第 7 章中学到的关于如何将代码分解为模块和文件那样。
tests 目录文件行为上的差异最明显，当你有一组辅助函数要在多个集成测试文件中使用，并且你尝试遵循 “将模块分离到不同文件中” 中的步骤时第 7 章的部分，将它们提取到一个公共模块中。例如，如果创建 tests/common.rs 并将一个名为 setup 的函数放在其中，我们可以将一些我们希望从多个测试文件中的多个测试函数调用的代码添加到 setup 中
文件名: tests/common.rs
pub fn setup() {
// setup code specific to your library's tests would go here
}当我们再次运行测试时，我们会在测试输出中看到 common.rs 文件的新部分，尽管这个文件不包含任何测试函数，我们也没有从任何地方调用 setup 函数
$ cargo test
Compiling adder v0.1.0 (file:///projects/adder)
Finished `test` profile [unoptimized + debuginfo] target(s) in 0.89s
Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4)
running 1 test
test tests::internal ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
Running tests/common.rs (target/debug/deps/common-92948b65e88960b4)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
Running tests/integration_test.rs (target/debug/deps/integration_test-92948b65e88960b4)
running 1 test
test it_adds_two ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
Doc-tests adder
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
common 出现在测试结果中并显示 running 0 tests 并不是我们想要的。我们只是想与其他集成测试文件共享一些代码。为了避免 common 出现在测试输出中，不再创建 tests/common.rs，而是创建 tests/common/mod.rs。现在项目目录看起来像这样
├── Cargo.lock
├── Cargo.toml
├── src
│ └── lib.rs
└── tests
├── common
│ └── mod.rs
└── integration_test.rs
这是 Rust 也理解的旧命名约定，正如我们在 “备选的文件路径” 中提到的那样在第 7 章中。以这种方式命名文件会告诉 Rust 不要将 common 模块视为集成测试文件。当我们将 setup 函数代码移到 tests/common/mod.rs 并删除 tests/common.rs 文件时，测试输出中的那一部分将不再出现。tests 目录的子目录中的文件不会被编译成独立的 crate，也不会在测试输出中拥有独立的部分。
创建了 tests/common/mod.rs 之后，我们可以从任何集成测试文件中将其作为一个模块来使用。这是从 tests/integration_test.rs 中的 it_adds_two 测试调用 setup 函数的一个例子
文件名: tests/integration_test.rs
use adder::add_two;
mod common;
#[test]
fn it_adds_two() {
common::setup();
let result = add_two(2);
assert_eq!(result, 4);
}注意，mod common; 声明与我们在 Listing 7-21 中展示的模块声明相同。然后，在测试函数中，我们可以调用 common::setup() 函数。
二进制 crate 的集成测试
如果我们的项目是一个二进制 crate，只包含一个 src/main.rs 文件而没有 src/lib.rs 文件，我们就无法在 tests 目录中创建集成测试，并通过 use 语句将定义在 src/main.rs 文件中的函数引入作用域。只有库 crate 会暴露可以供其他 crate 使用的函数；二进制 crate 是为了独立运行而存在的。
这是提供二进制文件的 Rust 项目通常有一个简单的 src/main.rs 文件，该文件调用位于 src/lib.rs 文件中的逻辑的原因之一。使用这种结构，集成测试 可以 使用 use 测试库 crate，从而使重要功能可用。如果重要功能正常工作，那么 src/main.rs 文件中的少量代码也会正常工作，并且那少量代码不需要被测试。
总结
Rust 的测试特性提供了一种方式来指定代码应该如何运行，以确保即使在你进行更改时它也能继续按预期工作。单元测试分别演练库的不同部分，并且可以测试私有的实现细节。集成测试检查库的许多部分是否协同工作正常，并且它们使用库的公共 API 以外部代码使用它的相同方式测试代码。尽管 Rust 的类型系统和所有权规则有助于防止某些类型的 bug，但测试仍然很重要，可以减少与代码预期行为相关的逻辑 bug。
让我们结合你在本章和之前章节学到的知识，来着手一个项目吧！