端到端测试Rust服务

发表于 10月以前 | 总阅读数：311 次

如果你正在用Rust构建web API，需要一种方法来端到端测试你的端点。单元测试可以确保你的逻辑是正确的，但是适当的端到端测试可以验证基础设施、路由、数据库迁移和安全设置是否正确。最好的方法之一是在CI/CD过程中进行端到端测试。对于Rust服务，Cargo使这个过程变得轻松。

端到端测试的要点

使用端到端测试是从客户的角度体验你的服务，你不仅要验证逻辑是否正确(可以通过单元测试进行验证)，还要验证软件、硬件、网络和权限是否能够协同工作。具有良好覆盖率的健壮的端到端测试还可以帮助检测基础结构中的组件，使你能够自信地进行基础结构的更改。

惯用的Rust测试

Cargo是一个包管理器，它封装了一些其他标准工具，包括格式化器、筛选器，以及对我们来说最重要的测试工具。cargo test，我们可以使用Rust提供的内置注释和支持来处理所有可能需要的测试，包括源文件中的单元测试和tests目录中的集成测试。

编写单元测试很简单，在编写应用程序代码的文件中添加一个测试模块，并添加一些#[test]注释。这里有一个例子：

#[cfg(test)]
mod tests {
  #[test]
  fn run_test() {
    // foo
  }
}

由于有#[cfg(test)]注释，编译器知道在实际构建中不包含此代码。只有在执行cargo test时才编译并运行它。

对于集成测试，我们只想测试API中公开的部分，因此按照惯例，这些测试将放在单独的测试目录中，在该目录中它们不能访问任何私有代码。与单元测试类似，这些测试需要用#[test]注释，并且只能由cargo test运行。

虽然我们的代码应该总是有单元测试，但我们在本文中的主要关注点实际上是那些集成测试。如果你正在编写一个Rust库，打算供其他Rust代码使用，那么你可能需要测试一个公共Rust API。但在我们的例子中，我们讨论的是提供web API的服务。我们没有Rust API。相反，我们将通过网络发出一些HTTP请求，它们可能是异步的。这改变了我们编写这些测试的方法。

分别运行单元测试和端到端测试

运行端到端测试带来的第一个变化是，你可能希望分别运行单元测试和集成测试。默认情况下，cargo test将同时运行单元测试和集成测试。如果正在测试的代码都在本地可用，这就不是问题。它之所以快是因为没有网络延迟，而且还可以在最新的代码上运行测试。但是，当在实际的非prod环境中运行测试时，测试可能需要更长的时间，并且需要将新代码部署到该环境中，然后才能对其进行测试。

由于部署可能很长(至少几分钟)，你可能希望在部署之前运行单元测试。如果逻辑不正确，把代码放在那里是没有意义的！因此，在运行任何端到端测试之前运行单元测试。然后，就可以自由部署了。只有在部署之后，才能运行端到端测试。

有两种方法可以实现这种分离：

1，使用Rust内置的#[ignore]注释

使用#[ignore]注释是更简单的方法，当你在tests目录中编写端到端测试并使用#[test]注释它们时，继续在下一行添加#[ignore]，如下所示：

#[test]
#[ignore]
fn run_test() {
  // foo
}

现在，当运行cargo test时，任何带有#[ignore]的测试都将被跳过！如果我们正确地注释了我们的测试，这意味着cargo test将只运行单元测试。然后，当要运行端到端测试时，可以执行cargo test --ignored，它将只执行忽略的测试！

但是，如果想忽略其他测试，则此方法可能会失效。有些测试可能正在开发中，不希望它们作为单元测试或集成测试步骤的一部分运行。在这种情况下，不能依靠#[ignore]来区分单元测试和集成测试。作为一种替代方法，我更喜欢使用环境变量来控制测试何时运行。

2，使用环境变量来配置测试

使用环境变量配置测试可能很有用，原因有很多，包括控制测试的运行时间。对于配置变量，我喜欢用“E2E_”作为前缀，以保持所有内容的组织性和可读性。使用环境变量来启用/禁用端到端测试，并在它们开始之前添加一些延迟，以便服务器有时间启动。

由于需要在多个集成测试中重用配置，因此将配置代码分解为单独的模块。在集成测试目录中设置模块非常简单：添加一个新目录，并在该目录中放置一个带有代码的mod.rs文件。如果模块很复杂，可以在新目录中放置多个文件，并在mod.rs文件中导出想要的任何代码，就像处理普通源代码一样。

然后，需要在顶级集成测试文件中引用该模块，就像在main.rs或lib.rs文件中声明模块一样。

以下是实际应用程序中使用的一些测试配置代码：

pub struct TestConfig {
    pub is_enabled: bool,
    pub delay_start_min: u64,
    pub env_name: String,
}

pub fn test_config() -> TestConfig {
    let is_enabled = env::var("E2E_ENABLE")
        .map(|s| &s.to_lowercase() == "true" || &s == "1")
        .unwrap_or(false);
    let delay_start_min = env::var("E2E_DELAY_START_MIN")
        .unwrap_or(String::from("0"))
        .parse::<u64>()
        .unwrap_or(0);
    let env_name = env::var("E2E_ENV_NAME").unwrap_or_else(|_| String::from("local"));

    TestConfig {
        is_enabled,
        delay_start_min,
        env_name,
    }
}

在测试函数中，可以调用这个test_config()函数来获得一个包含配置的TestConfig结构体。如果没有设置环境变量，配置将使用一些合理的默认值。如果没有显式地将E2E_ENABLE设置为true或1，那么测试将被禁用。如果没有设置E2E_DELAY_START_MIN(或者设置为非数值)，则默认为无延迟。

最后，如果E2E_ENV_NAME没有设置(例如，dev或staging)，那么它将默认为local，以防万一针对localhost或类似的东西运行测试。然后可以在测试函数中引用这个TestConfig来跳过、延迟或生成特定于环境的模拟数据(例如，获取存在于暂存数据库中的用户id)。

这里的默认设置是，当不设置E2E_ENABLE的情况下运行cargo测试时，将只运行单元测试。然后，当准备好只运行集成测试时，可以将E2E_ENABLE设置为true或1，然后运行cargo test。还可以通过传入模块名称，筛选到想要的测试。如果将测试分组为内聚单元，然后将这些单元放入它们自己的文件中，这将非常容易。

3，分组测试

对测试进行分组并将组分开是很简单的。默认情况下，tests目录顶层的每个文件都被编译为自己的crate，因此每个文件都是独立的，可以将相关的测试合并到这些文件中。

假设有一个REST API，其中包含两个不同的资源apple和orange。可以将测试代码分别写入到两个文件：apple_tests.rs和orange_tests.rs中，每个测试文件都可以依赖于test_config模块，并使用公共test_config()函数拉入测试配置。最重要的是，可以在运行cargo test时使用这些文件名来筛选测试。可以这样做：

cargo test apple_tests orange_tests

异步测试

最重要的是，我们需要使用async运行测试。许多用于发出HTTP请求的Rust库都是异步的，所以需要在异步函数中运行它们。然而，Rust测试在默认情况下不支持异步。我们需要引入另一个库来实现这一点。

最著名的是使用tokio库提供的test宏。这个宏设置了一个Tokio运行时来包装测试，允许将测试函数异步化。它非常容易使用：只需将#[tokio::test]替换为正在使用的#[test]注释，就可以了！

一个类似的替代方法是使用actix_rt库，如果已经在使用actix-web来编写的web API，这个方法会更简单。这个crate被建议用于为actix-web的web API代码运行异步单元测试，这意味着如果项目正在使用actix-web，只需要在测试中使用#[actix_rt::test]注释即可！