6.3 测试框架

Rust的单元测试不包括其他单元测试框架中可能找到的辅助函数、夹具、测试框架或参数化测试功能。对于这些功能，你需要自己编写代码或者尝试一些库。

对于基本的参数化测试，parameterized（https://crates.io/crates/parameterized）这个crate提供了一个创建测试的漂亮接口。test-case（https://crates.io/crates/test-case）这个crate提供了另一种参数化测试的实现，它简单、简洁且易于使用。对于夹具，你可以尝试rstest（https://crates.io/crates/rstest）这个crate。assert2（https://crates.io/crates/assert2）这个crate提供了受流行的C++ Catch2库启发的断言。

值得一提的是proptest（https://lib.rs/crates/proptest）这个crate，它提供了Rust实现的QuickCheck（https://github.com/nick8325/quickcheck），这是一个最初于1999年发布的Haskell库，你可能已经遇到过。Proptest并不是QuickCheck到Rust的1:1端口，而是提供了等效功能，并带有一些Rust特有的差异，这些差异在http://mng.bz/YRno上有文档记录。

属性测试通过生成随机测试数据、验证结果，并反馈创建错误所需的最小测试用例，可以为你节省大量时间。这是一个巨大的时间节省，尽管它不一定是验证已知值（例如，验证规范合规性）测试的替代品。

注意：属性测试没有免费午餐；它带来的权衡是可能需要花费更多的CPU周期来测试随机值，而不是选择或已知的值。你可以调整要测试的随机值的数量，但对于可能值集很大的数据，通常不切实际去测试每一个结果。

让我们回顾一下前一节中的加法器示例，但这次，我们将尝试使用proptest，它将为我们的测试函数提供测试数据。

现在，让我们再次使用 proptest运行这个测试。

哎呀！看来我们的加法器并不像我们想象的那么好。结果表明，在某些情况下它可能会“爆炸”（在这种情况下，是因为我们正在将两个有限长度的有符号整数相加，导致加法操作溢出）。我们没有预料到这种失败，除非我们手动为a和b生成随机数据，否则可能无法发现这个问题。

Rust中的算术溢出

在Rust中进行算术运算可能会让人一开始感到困惑，尤其是在进行测试时。

这有一个简单的原因：在Rust中，以调试模式编译的代码（例如，测试）默认使用检查过的算术。当相同的代码以发布模式编译时，它将使用未检查的算术。因此，你可能会有在调试模式下运行失败但在生产环境中运行良好的代码（即，不会产生错误或崩溃程序）。Rust的方法可能会有些令人困惑，因为代码的行为会根据编译方式的不同而不同。Rust中的理由是测试代码应该更严格以捕捉更多的错误，但为了兼容性，代码应该在运行时表现得像大多数其他程序一样。

开发者有时会忽视算术溢出，因为大多数语言要么模仿像C这样的语言的行为（通常被称为环绕算术；即当整数溢出时它只是环绕）。Rust为原始类型提供了许多替代的算术函数，这些函数在标准库中为每种类型都有文档记录。例如，i32提供了checked_add()、unchecked_add()、carrying_add()、wrapping_add()、overflowing_add()和saturating_add()。

要模拟C的行为，你可以使用Wrapping结构体（在http://mng.bz/G97M有文档记录）或为每种类型和操作调用相应的函数。

这种行为在RFC 560（http://mng.bz/z01w）中有记录。

我们有几个选项来修复之前的测试，但最简单的一个就是明确地处理溢出（即，遵循C语言中整数溢出的行为）。让我们更新我们的代码，使其看起来像这样：

我们已经向前面的代码中添加了num_traits crate，这是一个提供WrappingAdd trait的小型库。Rust标准库中没有等效的trait，没有它，用这种方式创建泛型函数是困难的（我们将在第8章和第9章更深入地探讨traits）。

如果我们现在运行我们的代码，它会按预期通过:

6.4 什么不需要测试：为什么编译器比你更了解

Rust 是一种静态类型语言，这带来了许多主要优势，特别是在测试方面。一种看待静态类型语言与动态类型语言不同的方式是，编译器在代码运行之前通过分析源代码来限制任何给定语句或代码块的可能输入和输出集。输入和输出的可能集由类型规范限制。也就是说，字符串不能是整数，反之亦然。编译器验证类型是否与预期匹配以及引用是否有效。你无需担心在运行时混淆字符串和整数。

因为编译器不允许这种情况发生；这免除了你（开发者）的担忧，只要你正确使用类型。在动态类型语言中，类型错误是最常见的问题之一。在解释型语言中，无效语法和类型错误的结合为运行时错误创造了强大的机会，这些错误在代码发布之前可能很难捕捉到。许多动态语言已经配备了静态分析工具，但它们并不总是足够严格或彻底地捕捉常见的错误。

当谈到测试时，我们永远不需要测试编译器或借用检查器已经为我们测试过的东西。例如，我们不需要检查一个整数是否是整数或一个字符串是否是字符串。我们不需要检查引用是否有效或数据是否被两个不同的线程（竞争条件）改变。

让我们明确一点，这并不意味着你不需要测试——它只是意味着你在Rust中测试的大部分是逻辑，而不是类型验证或内存使用。的确，你仍然需要执行类型转换，这些可能会失败，但处理这些是逻辑问题。Rust的人体工程学使得处理可能失败的事物变得困难。

在Rust中正确地进行测试始于有效使用Rust的类型系统。过度使用Option、unwrap()或不安全代码可能导致更难发现的错误，特别是如果你使用这些特性作为避免处理边缘情况的方式。有状态的操作和I/O需要被适当检查和处理（作为一个好习惯，执行I/O的函数或方法应该可能返回一个Result）。