测试
测试
程序测试是一个非常有效的方法，它可以有效的暴漏程序中的缺陷，但对于暴漏缺陷来说，这还是远远不够的。
—— Edsger W. Dijkstra，"卑微的程序员" (1972)
让我们来谈谈如何测试 Rust 代码。我们将谈论不是什么测试 Rust 代码正确的方法。关于正确和错误地编写测试的方式有很多的流派。所有这些方法都使用相同的基本工具，因此，我们将向您展示使用它们的语法。
测试属性
Rust 中一个最简单的测试是一个函数，它使用 test 属性注释。让我们使用 Cargo 做一个叫加法器的新项目：
$ cargo new adder
$ cd adder当你做一个新项目时，Cargo 将自动生成一个简单的测试。下面即是 src/lib.rs 的内容：
#[test]
fn it_works() {
}注意 #[test]。该属性表明，这是一个测试函数，目前还没有函数体。我们可以使用 Cargo test 运行这个测试：
$ cargo test
Compiling adder v0.0.1 (file:///home/you/projects/adder)
Running target/adder-91b3e234d4ed382a
running 1 test
test it_works ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
Doc-tests adder
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measuredCargo 编译和运行我们的测试。这里有两组输出：一个用于我们写的测试，另一个用于文档测试。稍后我们将讨论这一问题。现在，让我们来看看这一行：
test it_works ... ok注意 it_works。这是来自我们的函数的名称:
fn it_works() {我们还得到一个总结:
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured那么为什么我们的测试能够通过呢?任何非 panic 的测试都可以通过，任何 panic 的测试都会失败。让我们来看一个失败的测试：
#[test]
fn it_works() {
assert!(false);
}assert! 一种 Rust 提供的宏，它需要一个参数：如果参数是true，什么也不会发生。如果参数是 false，它就成为 panic！ 的。让我们再次运行我们的测试：
$ cargo test
Compiling adder v0.0.1 (file:///home/you/projects/adder)
Running target/adder-91b3e234d4ed382a
running 1 test
test it_works ... FAILED
failures:
---- it_works stdout ----
thread 'it_works' panicked at 'assertion failed: false', /home/steve/tmp/adder/src/lib.rs:3
failures:
it_works
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured
thread '<main>' panicked at 'Some tests failed', /home/steve/src/rust/src/libtest/lib.rs:247Rust 表明我们的测试失败：
test it_works ... FAILED反映在结论中就是：
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured还可以得到一个非零的状态代码：
$ echo $?
101如果你想将 cargo test 集成到其他工具，这是非常有用的。
我们可以用另一个属性：should_panic 转化我们的测试的失败：
#[test]
#[should_panic]
fn it_works() {
assert!(false);
}如果我们 panic！，这个测试会成功，如果我们完成，则测试会失败。让我们来试一试：
$ cargo test
Compiling adder v0.0.1 (file:///home/you/projects/adder)
Running target/adder-91b3e234d4ed382a
running 1 test
test it_works ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
Doc-tests adder
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measuredRust 提供另一个宏 assert_eq!，用来比较两个参数是否相等：
#[test]
#[should_panic]
fn it_works() {
assert_eq!("Hello", "world");
}这个测试是否可以通过?因为存在 should_panic 属性，它可以通过：
$ cargo test
Compiling adder v0.0.1 (file:///home/you/projects/adder)
Running target/adder-91b3e234d4ed382a
running 1 test
test it_works ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
Doc-tests adder
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measuredshould_panic 测试很脆弱。很难保证测试不会因为一个意想不到的原因而失败。为了解决这个问题，可以在 should_panic 属性中添加一个可选的参数：expected。测试工具将确保错误消息包含提供的文本。上面示例的安全版本是：
#[test]
#[should_panic(expected = "assertion failed")]
fn it_works() {
assert_eq!("Hello", "world");
}这就是所有的基础让我们来编写一个“真正”的测试：
pub fn add_two(a: i32) -> i32 {
a + 2
}
#[test]
fn it_works() {
assert_eq!(4, add_two(2));
}这是 assert_eq! 的一个非常常见的用法：使用一些已知的参数调用某些函数并与预期的输出比较。
测试模块
有一种方式，以这种方式我们现有的例子都是不符合惯例的：它缺少测试模块。我们的示例的惯用写作方式，如下所示:
pub fn add_two(a: i32) -> i32 {
a + 2
}
#[cfg(test)]
mod tests {
use super::add_two;
#[test]
fn it_works() {
assert_eq!(4, add_two(2));
}
}这里有一些变化。第一个是引入带有 cfg 属性的 mod tests。模块允许我们对所有的测试进行分组，如果需要也可以定义 helper 函数，这个函数不会成为我们 crate 的一部分。如果目前我们试图运行这些代码，cfg 属性只会编译我们的测试代码。这可以节省编译时间，也保证了我们构建的测试是完全正常的。
第二个变化是 use 声明。因为我们在一个内部模块中，我们需要将我们的测试函数设置范围。如果你有一个大的模块，这可能就会很恼人，所以这是 glob 属性的一种常见的使用方式。让我们改变我们的 src/lib.rs 以便能够使用它：
pub fn add_two(a: i32) -> i32 {
a + 2
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn it_works() {
assert_eq!(4, add_two(2));
}
}注意 use 行的不同使用方式。现在，我们来运行我们的测试：
$ cargo test
Updating registry `https://github.com/rust-lang/crates.io-index`
Compiling adder v0.0.1 (file:///home/you/projects/adder)
Running target/adder-91b3e234d4ed382a
running 1 test
test tests::it_works ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
Doc-tests adder
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured看，运转起来了!
当前的惯例是使用测试模块 “unit-style” 测试。任何只测试一个小功能都是有意义的。如果用 “integration-style” 测试替代会怎么样呢?为此，我们引出了测试目录。
测试目录
为了编写集成测试，让我们做一个测试目录，并把一个 tests/lib.rs 文件放在里面，这是它的内容：
extern crate adder;
#[test]
fn it_works() {
assert_eq!(4, adder::add_two(2));
}这类似于我们之前的测试，但略有不同。在代码顶部有一个 extern crate adder。这是因为在测试目录里测试是一个完全独立的箱，所以我们需要导入我们的函数库。这也是为什么 tests 是一个编写集成风格测试的合适的地方：他们使用函数库和其他消费者。
让我们运行它们:
$ cargo test
Compiling adder v0.0.1 (file:///home/you/projects/adder)
Running target/adder-91b3e234d4ed382a
running 1 test
test tests::it_works ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
Running target/lib-c18e7d3494509e74
running 1 test
test it_works ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
Doc-tests adder
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured现在我们有三个部分：我们之前的测试在运行，现在这个新的也在运行。
这就是所有的 tests 目录。这里不需要测试模块，因为整件事都是专注于测试的。
让我们最后检查一下第三部分：文档测试。
文档测试
没有什么是比带有示例的文档更好的了。没有什么是比不能真正工作的例子更糟的了，一直以来文档编写已经改变了代码习惯。为此，Rust 支持自动运行你的文档中的示例。这里有一个完整的 src/lib.rs 的例子：
//! The `adder` crate provides functions that add numbers to other numbers.
//!
//! # Examples
//!
//! ```
//! assert_eq!(4, adder::add_two(2));
//! ```
/// This function adds two to its argument.
///
/// # Examples
///
/// ```
/// use adder::add_two;
///
/// assert_eq!(4, add_two(2));
/// ```
pub fn add_two(a: i32) -> i32 {
a + 2
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn it_works() {
assert_eq!(4, add_two(2));
}
}
注意：模块级文档使用 //!，函数文档使用 ///。Rust 的文档支持 Markdown 中评论，所以三重斜线标志代码块。包含 # Examples 部分是一种惯例，以下所示。
让我们再次运行测试:
$ cargo test
Compiling adder v0.0.1 (file:///home/steve/tmp/adder)
Running target/adder-91b3e234d4ed382a
running 1 test
test tests::it_works ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
Running target/lib-c18e7d3494509e74
running 1 test
test it_works ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
Doc-tests adder
running 2 tests
test add_two_0 ... ok
test _0 ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured现在我们运行了所有三种测试！注意这些测试文档的名称：the_0 生成模块测试，add_two_0 生成功能测试。当你添加更多的例子，这些名字会自动增量（例如 add_two_1）。