6 个稳定版本

3.0.2	2023年12月1日
3.0.1	2023年3月6日
3.0.0	2023年3月5日
2.0.0	2022年8月5日
1.0.1	2022年5月12日

59 / 测试

6,496 次每月下载
在 7 个 crates 中使用

MIT 许可证

36KB
285 代码行

test-binary

将集成测试的额外二进制文件作为常规 Rust crate 管理和构建。

如果您对涉及子进程管理、进程间通信或平台工具的内容进行集成测试，您可能需要编写一些额外的“辅助”二进制文件来帮助进行这些测试。例如，如果您想测试您的代码对管理子进程的退出状态的处理是否正确，您可能需要一个可以以特定状态码退出的辅助二进制文件。如果您正在测试 IPC 交换，您可能希望测试一个发送一些脚本回复的二进制“模拟”。

如果您已经使用 Cargo 进行构建和测试，那么能够将这些额外二进制文件用 Rust 编写，并将其放在您正在测试的 crate 附近，作为 Cargo 项目本身，将非常方便。这样，至少您可以确保您的测试环境已经安装了正确的工具链。

在一定程度上，即使不使用此 crate 也可以实现这一点！ 如果您需要一个额外的二进制文件，您可以将其放在您的 src/bin 或 examples 目录下，并按这种方式使用它。但是，仅使用 Cargo 独立可做的事情存在限制。

crate 二进制文件，例如在 src/bin 下，或在 Cargo.toml 中的 [[bin]] 下列出，可以通过运行测试时使用的环境变量 CARGO_BIN_EXE_<name> 查找。但它们必须与您的整个 crate 共享依赖！因此，无论您的辅助二进制文件依赖于什么，您的整个 crate 也必须依赖。这在 Cargo 问题 #1982 中进行了讨论。



示例二进制文件（位于 examples/ 或 [[example]]）使用 [dev-dependencies] 代替。但它们没有等效的环境变量，可能在测试运行之前无法构建。


从更哲学的角度来看：这样的二进制文件既不是示例，也不是真实的应用程序。它们可能根本不使用您仓库的任何方面。它们可能故意出现故障。对于最终用户来说，在您的其他示例中找到这些二进制文件可能会令人困惑。这可能并不是您希望为测试组织的类型。


将支持二进制文件作为工作区仓库组织需要将每个这样的仓库发布到 crates.io（或您正在使用的任何注册表），即使它们在您的仓库集成测试之外没有任何用途。


此仓库提供了一种绕过这些限制的方法。它有一个简单的接口来调用 Cargo 构建您仓库下单独目录中的额外二进制文件。
首先要注意的是，这些额外二进制文件 不是 实际项目清单中列出的二进制文件。所以，首先选择一个目录名，并将它们放在那里，例如，该项目使用 testbins。 这不会成为一个工作区。 在此目录下，您将在自己的 Cargo 包中拥有这些额外二进制文件。
结构应类似于以下内容
├── Cargo.toml        (your crate's manifest)
├── src
│  └── lib.rs         (your crate's lib.rs)
├── tests
│  └── tests.rs       (your crate's tests, which want to use the supporting
│                      binaries below)
│
└── testbins          (all the extra binary projects are under this
   │                   directory)
   ├── test-something (first extra binary)
   │  ├── Cargo.toml  (extra binary manifest, name = "test-something")
   │  └── src
   │     └── main.rs  (extra binary source)
   ├── test-whatever  (another extra binary, name = "test-whatever")
   │  ├── Cargo.toml
   │  └── src
   │     └── main.rs
    ...etc...


注意
在 Cargo.toml 中为这些测试二进制文件添加一个空的 [workspace] 部分，这样 Cargo 就知道不要在父目录中查找，这可能很有用。

有了这种设置，您现在可以调用 build_test_binary("test-something", "testbins")。看看它是如何

"test-something" 是您传递给 Cargo 的二进制文件名 在子项目 中，例如，如果您切换到嵌套项目，您将运行 cargo build --bin test-something；它也必须是该项目所在的子目录的名称
"testbins" 是包含此测试二进制项目的目录相对于您的真实项目清单的相对路径（也许还有其他一些）；就像您看待 examples 或 tests 目录一样

如果您需要设置不同的配置文件或功能，或对目录结构有更多控制，还有一个 构建器 API。还可以查看 build_test_binary_once!() 宏，它懒加载二进制并缓存路径。
以下是如何在测试中使用此仓库 API 的示例，二进制文件名为 does-build

let test_bin_path = build_test_binary("does-build", "testbins")
    .expect("error building test binary");

let mut test_bin_subproc = std::process::Command::new(test_bin_path)
    .spawn()
    .expect("error running test binary");

// Test behaviour of your program against the mock binary eg. send it
// something on stdin and assert what it prints on stdout, do some IPC,
// check for side effects.

assert!(test_bin_subproc
    .wait()
    .expect("error waiting for test binary")
    .success());

这些函数返回的结果包含构建的二进制文件的路径，该路径作为一个 std::ffi::OsString，可以传递给 std::process::Command 或其他处理子进程的crate。此crate不会将路径解析为绝对路径，尽管它可能已经是绝对路径。因为它是在当前进程的工作目录中调用Cargo后提供的路径，所以在您在获取和使用它之间不更改工作目录的情况下，它将是有效的。

最低支持的Rust版本：1.57。在LICENSE文件中受MIT许可证的许可。
此文档通过cargo-rdme保持最新。



依赖项

~1–2MB


~40K SLoC



camino


cargo_metadata 0.15

once_cell


paste


thiserror




 dev  indoc 2.0