如何编写测试 -- Rust教程|Rust中文文档|Rust编程|Rust官方文档

而不是ok、该线test tests::another显示FAILED.两个新各个部分出现在各个结果和摘要之间：第一个显示每个测试失败的详细原因。在这种情况下，我们得到详细信息another失败是因为它panicked at 'Make this test fail'上 src/lib.rs 文件中的第 17 行。下一部分仅列出所有失败的测试，这在存在大量测试和大量详细的失败测试输出。我们可以使用失败测试的名称来运行 that test 以更轻松地调试它;我们将更多地讨论在 “控制测试的运行方式”部分。

摘要行显示在末尾：总体而言，我们的测试结果为FAILED.我们有 1 次测试通过和 1 次测试失败。

现在，您已经了解了不同场景中的测试结果，让我们看看panic!在测试中很有用。

使用`assert!`宏

这assert!宏，当您需要时非常有用确保测试中的某些 condition 的计算结果为true.我们给出assert!macro 是一个计算结果为 Boolean 的参数。如果值为true，则什么都没有发生，测试通过。如果值为false这assert!宏调用panic!导致测试失败。使用assert!macro 帮助我们检查代码是否按预期运行。

在第 5 章示例 5-15 中，我们使用了Rectanglestruct 和can_hold方法，在示例 11-5 中重复。让我们把这段代码放在 src/lib.rs 文件中，然后使用assert!宏。

文件名： src/lib.rs

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn can_hold(&self, other: &Rectangle) -> bool {
        self.width > other.width && self.height > other.height
    }
}

示例 11-5：Rectanglestruct 及其can_hold第 5 章中的方法

这can_holdmethod 返回一个 Boolean，这意味着这是一个完美的用例对于assert!宏。在示例 11-6 中，我们编写了一个测试，该测试执行can_hold方法，方法是创建一个Rectangle宽度为 8 且高度为 7 并断言它可以容纳另一个Rectangle实例，该实例宽度为 5，高度为 1。

文件名： src/lib.rs

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn can_hold(&self, other: &Rectangle) -> bool {
        self.width > other.width && self.height > other.height
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn larger_can_hold_smaller() {
        let larger = Rectangle {
            width: 8,
            height: 7,
        };
        let smaller = Rectangle {
            width: 5,
            height: 1,
        };

        assert!(larger.can_hold(&smaller));
    }
}

示例 11-6：对can_hold检查较大的 Rectangle 是否确实可以容纳较小的 Rectangle

请注意use super::*;行内的tests模块。这testsmodule 为一个常规模块，遵循我们在章节中介绍的通常可见性规则 7 在“引用模块中项目的路径” Tree“部分。因为testsmodule 是一个内部的 module，我们需要带来外部模块中的待测试代码添加到内部模块的范围内。我们使用一个 glob，所以我们在外部模块中定义的任何东西都可以用于 thistests模块。

我们已将我们的测试命名为larger_can_hold_smaller，我们创建了两个Rectangle实例。然后我们调用assert!macro 和将调用larger.can_hold(&smaller).此表达式为应该返回true，因此我们的测试应该通过。让我们来了解一下！

$ cargo test
   Compiling rectangle v0.1.0 (file:///projects/rectangle)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.66s
     Running unittests src/lib.rs (target/debug/deps/rectangle-6584c4561e48942e)

running 1 test
test tests::larger_can_hold_smaller ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests rectangle

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

它确实通过了！让我们添加另一个测试，这次断言一个较小的 rectangle 无法容纳更大的 rectangle：

文件名： src/lib.rs

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn can_hold(&self, other: &Rectangle) -> bool {
        self.width > other.width && self.height > other.height
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn larger_can_hold_smaller() {
        // --snip--
        let larger = Rectangle {
            width: 8,
            height: 7,
        };
        let smaller = Rectangle {
            width: 5,
            height: 1,
        };

        assert!(larger.can_hold(&smaller));
    }

    #[test]
    fn smaller_cannot_hold_larger() {
        let larger = Rectangle {
            width: 8,
            height: 7,
        };
        let smaller = Rectangle {
            width: 5,
            height: 1,
        };

        assert!(!smaller.can_hold(&larger));
    }
}

因为can_hold函数是false, 我们需要在将该结果传递给assert!宏。作为 result，如果can_hold返回false:

$ cargo test
   Compiling rectangle v0.1.0 (file:///projects/rectangle)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.66s
     Running unittests src/lib.rs (target/debug/deps/rectangle-6584c4561e48942e)

running 2 tests
test tests::larger_can_hold_smaller ... ok
test tests::smaller_cannot_hold_larger ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests rectangle

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

通过两项测试！现在让我们看看当我们在我们的代码中引入一个 bug。我们将更改can_hold方法，将大于号替换为小于号比较宽度：

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

// --snip--
impl Rectangle {
    fn can_hold(&self, other: &Rectangle) -> bool {
        self.width < other.width && self.height > other.height
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn larger_can_hold_smaller() {
        let larger = Rectangle {
            width: 8,
            height: 7,
        };
        let smaller = Rectangle {
            width: 5,
            height: 1,
        };

        assert!(larger.can_hold(&smaller));
    }

    #[test]
    fn smaller_cannot_hold_larger() {
        let larger = Rectangle {
            width: 8,
            height: 7,
        };
        let smaller = Rectangle {
            width: 5,
            height: 1,
        };

        assert!(!smaller.can_hold(&larger));
    }
}

现在运行测试会产生以下结果：

$ cargo test
   Compiling rectangle v0.1.0 (file:///projects/rectangle)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.66s
     Running unittests src/lib.rs (target/debug/deps/rectangle-6584c4561e48942e)

running 2 tests
test tests::larger_can_hold_smaller ... FAILED
test tests::smaller_cannot_hold_larger ... ok

failures:

---- tests::larger_can_hold_smaller stdout ----
thread 'tests::larger_can_hold_smaller' panicked at src/lib.rs:28:9:
assertion failed: larger.can_hold(&smaller)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    tests::larger_can_hold_smaller

test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--lib`

我们的测试发现了错误！因为larger.width是8和smaller.width是5中，比较can_hold现在返回false： 8 不是小于 5。

使用`assert_eq!`和`assert_ne!`宏

验证功能的一种常见方法是测试结果之间的相等性）和您希望代码返回的值。你可以通过使用assert!宏，并使用运算符向其传递表达式。但是，这是一个非常常见的测试，标准库提供一对宏 -==assert_eq!和assert_ne!- 执行此测试更方便。这些宏比较两个参数是否相等或不等式。如果断言 fails 的 Fails，这样更容易看到测试失败的原因;相反，assert!macro 仅表示它获得了false值，而不打印导致==false价值。

在示例 11-7 中，我们编写了一个名为add_two这增加了2到其参数，那么我们使用assert_eq!宏。

文件名： src/lib.rs

pub fn add_two(a: usize) -> usize {
    a + 2
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_adds_two() {
        let result = add_two(2);
        assert_eq!(result, 4);
    }
}

示例 11-7：测试函数add_two使用assert_eq!宏

让我们检查一下它是否通过！

$ cargo test
   Compiling adder v0.1.0 (file:///projects/adder)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.58s
     Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4)

running 1 test
test tests::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

我们创建一个名为result，它保存调用add_two(2).然后我们传递result和4作为参数，将assert_eq!. 此测试的输出行为test tests::it_adds_two ... ok和oktext 表示我们的测试通过！

让我们在代码中引入一个 bug，看看是什么assert_eq!看起来当它失败。更改add_two函数来添加3:

pub fn add_two(a: usize) -> usize {
    a + 3
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_adds_two() {
        let result = add_two(2);
        assert_eq!(result, 4);
    }
}

再次运行测试：

$ cargo test
   Compiling adder v0.1.0 (file:///projects/adder)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.61s
     Running unittests src/lib.rs (target/debug/deps/adder-92948b65e88960b4)

running 1 test
test tests::it_adds_two ... FAILED

failures:

---- tests::it_adds_two stdout ----
thread 'tests::it_adds_two' panicked at src/lib.rs:12:9:
assertion `left == right` failed
  left: 5
 right: 4
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    tests::it_adds_two

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--lib`

我们的测试发现了错误！这it_adds_twotest failed，并且消息告诉我们assertion `left == right` failed以及left和right值是。此消息可帮助我们开始调试：left参数，而我们调用add_two(2)是5但是rightargument 是4. 您可以想象，当我们有很多测试正在进行中。

请注意，在某些语言和测试框架中，相等的参数断言函数被调用expected和actual和我们指定参数很重要。但是，在 Rust 中，它们被称为left和right，以及我们指定预期值和值的顺序代码生成无关紧要。我们可以将此测试中的断言写为assert_eq!(4, result)，这将产生相同的失败消息显示assertion failed: `(left == right)`.

这assert_ne!如果我们给它的两个值不相等，则 macro 将传递，如果它们相等，则失败。这个宏在我们不确定的情况下最有用值会是什么，但我们知道值绝对不应该是什么。例如，如果我们正在测试一个保证会更改其输入的函数在某种程度上，但 input 的更改方式取决于在我们运行测试的那一周，最好断言的可能是函数的 output 不等于 input。

在表面之下，assert_eq!和assert_ne!宏使用运算符和==!=分别。当断言失败时，这些宏会打印其使用调试格式的参数，这意味着要比较的值必须实现PartialEq和Debug性状。所有基元类型和大多数标准库类型实现这些特征。对于结构体和枚举你定义自己，你需要实施PartialEq要断言那些类型。您还需要实施Debug以打印断言失败。因为这两个 trait 都是可派生的 trait，如中所述示例 5-12 中，这通常与添加#[derive(PartialEq, Debug)]注解添加到您的结构或枚举定义中。看附录 C，“可衍生性状”，了解更多信息有关这些特征和其他可派生特征的详细信息。

添加自定义失败消息

您还可以添加自定义消息，以将失败消息打印为可选参数添加到assert!,assert_eq!和assert_ne!宏。任何在将所需参数传递给format!宏（在第 8 章的“与 Operator 或+format!宏”部分），因此您可以传递包含占位符和值以放入这些占位符中。自定义消息可用于记录断言的含义;当测试失败时，您将更好地了解问题出在代码上。{}

例如，假设我们有一个按名字问候人们的函数，我们想要测试我们传递给函数的名称是否出现在输出中：

文件名： src/lib.rs

pub fn greeting(name: &str) -> String {
    format!("Hello {name}!")
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn greeting_contains_name() {
        let result = greeting("Carol");
        assert!(result.contains("Carol"));
    }
}

此计划的要求尚未达成一致，我们正在很确定Hello问候语开头的文本将发生变化。我们决定我们不想在需求发生变化时更新测试，因此，而不是检查是否与从greeting函数，我们只需断言输出包含 input 参数。

现在让我们通过更改greeting排除name要查看默认测试失败的情况：

pub fn greeting(name: &str) -> String {
    String::from("Hello!")
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn greeting_contains_name() {
        let result = greeting("Carol");
        assert!(result.contains("Carol"));
    }
}

运行此测试将生成以下内容：

$ cargo test
   Compiling greeter v0.1.0 (file:///projects/greeter)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.91s
     Running unittests src/lib.rs (target/debug/deps/greeter-170b942eb5bf5e3a)

running 1 test
test tests::greeting_contains_name ... FAILED

failures:

---- tests::greeting_contains_name stdout ----
thread 'tests::greeting_contains_name' panicked at src/lib.rs:12:9:
assertion failed: result.contains("Carol")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    tests::greeting_contains_name

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--lib`

此结果仅指示断言失败，以及断言已打开。更有用的失败消息将打印greeting功能。让我们添加一条由格式 string 中，其中的占位符填充了我们从greeting功能：

pub fn greeting(name: &str) -> String {
    String::from("Hello!")
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn greeting_contains_name() {
        let result = greeting("Carol");
        assert!(
            result.contains("Carol"),
            "Greeting did not contain name, value was `{result}`"
        );
    }
}

现在，当我们运行测试时，我们将收到一条信息量更大的错误消息：

$ cargo test
   Compiling greeter v0.1.0 (file:///projects/greeter)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.93s
     Running unittests src/lib.rs (target/debug/deps/greeter-170b942eb5bf5e3a)

running 1 test
test tests::greeting_contains_name ... FAILED

failures:

---- tests::greeting_contains_name stdout ----
thread 'tests::greeting_contains_name' panicked at src/lib.rs:12:9:
Greeting did not contain name, value was `Hello!`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    tests::greeting_contains_name

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--lib`

我们可以看到我们在测试输出中实际获得的值，这将对我们有所帮助调试发生了什么，而不是我们预期发生的事情。

检查 Panics`should_panic`

除了检查返回值之外，检查我们的代码是否按照我们的预期处理错误条件。例如，考虑Guess类型我们在第 9 章示例 9-13 中创建的。其他使用Guess取决于Guessinstances 将仅包含值介于 1 和 100 之间。我们可以编写一个测试，确保尝试创建一个Guess值超出该范围的实例 panic。

我们通过添加属性should_panic添加到我们的测试功能。这如果函数内部的代码 panic，则测试通过;如果代码内部的函数不会 panic。

示例 11-8 显示了一个测试，该测试检查Guess::new在我们预期的时候发生。

文件名： src/lib.rs

pub struct Guess {
    value: i32,
}

impl Guess {
    pub fn new(value: i32) -> Guess {
        if value < 1 || value > 100 {
            panic!("Guess value must be between 1 and 100, got {value}.");
        }

        Guess { value }
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    #[should_panic]
    fn greater_than_100() {
        Guess::new(200);
    }
}

示例 11-8：测试条件将导致panic!

我们将#[should_panic]属性#[test]attribute 和在它适用的 test 函数之前。让我们看看这个测试时的结果通过：

$ cargo test
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.58s
     Running unittests src/lib.rs (target/debug/deps/guessing_game-57d70c3acb738f4d)

running 1 test
test tests::greater_than_100 - should panic ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

   Doc-tests guessing_game

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

看起来不错！现在让我们通过删除条件该new如果该值大于 100，函数将 panic：

pub struct Guess {
    value: i32,
}

// --snip--
impl Guess {
    pub fn new(value: i32) -> Guess {
        if value < 1 {
            panic!("Guess value must be between 1 and 100, got {value}.");
        }

        Guess { value }
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    #[should_panic]
    fn greater_than_100() {
        Guess::new(200);
    }
}

当我们运行示例 11-8 中的测试时，它会失败：

$ cargo test
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.62s
     Running unittests src/lib.rs (target/debug/deps/guessing_game-57d70c3acb738f4d)

running 1 test
test tests::greater_than_100 - should panic ... FAILED

failures:

---- tests::greater_than_100 stdout ----
note: test did not panic as expected

failures:
    tests::greater_than_100

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--lib`

在这种情况下，我们没有收到非常有用的消息，但是当我们查看测试函数，我们看到它被注释为#[should_panic].我们得到的失败表示 test 函数中的代码没有导致 panic。

使用should_panic可能不精确。一个should_panic测试将通过，即使测试因与我们不同的原因而 panic 期待。要使should_panictesting 更精确，我们可以添加一个可选的expected参数添加到should_panic属性。测试框架将确保 failure 消息包含提供的文本。例如考虑修改后的代码Guess在示例 11-9 中，其中new功能 panics 并显示不同的消息，具体取决于值是否太小或太大了。

文件名： src/lib.rs

pub struct Guess {
    value: i32,
}

// --snip--

impl Guess {
    pub fn new(value: i32) -> Guess {
        if value < 1 {
            panic!(
                "Guess value must be greater than or equal to 1, got {value}."
            );
        } else if value > 100 {
            panic!(
                "Guess value must be less than or equal to 100, got {value}."
            );
        }

        Guess { value }
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    #[should_panic(expected = "less than or equal to 100")]
    fn greater_than_100() {
        Guess::new(200);
    }
}

示例 11-9：测试panic!包含包含指定子字符串的 panic 消息

此测试将通过，因为我们在should_panic属性的expectedparameter 是消息的子字符串，该Guess::newfunction panics with 一起。我们可以指定整个 panic 消息，即我们 expect 的 intent 函数，在本例中为Guess value must be less than or equal to 100, got 200.您选择指定的内容取决于 panic 的程度消息是唯一的或动态的，以及您希望测试的精确程度。在这个 case，则 panic 消息的子字符串足以确保 test 函数执行else if value > 100箱。

要查看should_panictest 替换为expected消息失败，让我们通过交换if value < 1和else if value > 100块：

pub struct Guess {
    value: i32,
}

impl Guess {
    pub fn new(value: i32) -> Guess {
        if value < 1 {
            panic!(
                "Guess value must be less than or equal to 100, got {value}."
            );
        } else if value > 100 {
            panic!(
                "Guess value must be greater than or equal to 1, got {value}."
            );
        }

        Guess { value }
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    #[should_panic(expected = "less than or equal to 100")]
    fn greater_than_100() {
        Guess::new(200);
    }
}

这一次，当我们运行should_panictest，它将失败：

$ cargo test
   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.66s
     Running unittests src/lib.rs (target/debug/deps/guessing_game-57d70c3acb738f4d)

running 1 test
test tests::greater_than_100 - should panic ... FAILED

failures:

---- tests::greater_than_100 stdout ----
thread 'tests::greater_than_100' panicked at src/lib.rs:12:13:
Guess value must be greater than or equal to 1, got 200.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
note: panic did not contain expected string
      panic message: `"Guess value must be greater than or equal to 1, got 200."`,
 expected substring: `"less than or equal to 100"`

failures:
    tests::greater_than_100

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--lib`

失败消息表明此测试确实如我们预期的那样出现 panic。但 panic 消息不包含预期的字符串less than or equal to 100.在这种情况下，我们确实收到的恐慌消息是Guess value must be greater than or equal to 1, got 200.现在我们可以开始弄清楚在哪里我们的 bug 是！

用`Result<T, E>`in 测试

到目前为止，我们的测试在失败时都会感到恐慌。我们还可以编写使用Result<T, E>!这是示例 11-1 中的测试，重写为使用Result<T, E>并返回一个Err而不是惊慌：

pub fn add(left: usize, right: usize) -> usize {
    left + right
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_works() -> Result<(), String> {
        let result = add(2, 2);

        if result == 4 {
            Ok(())
        } else {
            Err(String::from("two plus two does not equal four"))
        }
    }
}

这it_works函数现在具有Result<(), String>return 类型。在 body 的 body 函数，而不是调用assert_eq!宏，我们返回Ok(())当测试通过并且Err替换为String里面当测试失败。

编写测试，使其返回Result<T, E>使您能够使用问题 mark 运算符，这是一种方便的编写方式测试中，如果其中的任何作返回Err变体。

您不能使用#[should_panic]对使用Result<T, E>.要断言作返回Err变体，请不要使用问号运算符Result<T, E>价值。相反，请使用assert!(value.is_err()).

现在，您已经了解了编写测试的几种方法，让我们看看发生了什么当我们运行测试并探索我们可以使用的不同选项cargo test.

Rust 编程语言