14-cargo test

译文 · 基于 The Cargo Book

cargo-test(1)

原文链接: https://doc.rust-lang.org/cargo/commands/cargo-test.html

名称

cargo-test — 执行包的单元测试与集成测试

大纲

cargo test [options] [testname] [-- test-options]

描述

编译并执行单元测试、集成测试与文档测试。

测试过滤参数 TESTNAME 以及两个短划线（--）之后的所有参数都会传给测试二进制，进而传给 libtest（rustc 内置的单元测试与微基准测试框架）。若同时向 Cargo 与二进制传参，则 -- 之后的参数传给二进制，之前的传给 Cargo。关于 libtest 参数的详情，请参见 cargo test -- --help 的输出，以及 rustc 手册中关于测试工作原理的章节：https://doc.rust-lang.org/rustc/tests/index.html。

例如，以下命令会过滤名称中含 foo 的测试，并以 3 个线程并行运行：

cargo test foo -- --test-threads 3

测试使用 rustc 的 --test 选项构建，通过将你的代码与 libtest 链接来创建特殊可执行文件。该可执行文件会在多个线程中自动运行所有标注了 #[test] 属性的函数。标注了 #[bench] 的函数也会以一次迭代运行，以验证其功能正常。

若包包含多个测试目标，每个目标都会如上所述编译为特殊可执行文件，然后串行运行。

可通过在目标清单设置中将 harness = false 来禁用 libtest 框架，此时你的代码需要提供自己的 main 函数来处理测试的运行。

默认情况下，cargo test 使用 test 配置文件，它会启用调试。

文档测试

默认也会运行文档测试，由 rustdoc 处理。它从库目标的文档注释中提取代码示例并执行。

与普通测试目标不同，每个代码块都会用 rustc 即时编译为 doctest 可执行文件。这些可执行文件在独立进程中并行运行。代码块的编译实际上是由 libtest 控制的测试函数的一部分，因此某些选项（如 --jobs）可能不会生效。注意：doctest 的这种执行模型不保证稳定，将来可能变更；请谨慎依赖它。

关于编写文档测试的更多信息，请参见 rustdoc 手册。

测试的工作目录

运行每个单元测试与集成测试时，工作目录设为该测试所属包的根目录。 将测试的工作目录设为包的根目录，使测试能够使用相对路径可靠地访问包的文件，而无论从何处执行 cargo test。

对于文档测试，调用 rustdoc 时的工作目录设为工作空间根目录，这也是 rustdoc 用作每个文档测试编译目录的目录。 运行每个文档测试时的工作目录设为该测试所属包的根目录，并通过 rustdoc 的 --test-run-directory 选项控制。

选项

测试选项

--no-run

编译但不运行测试。

--no-fail-fast

无论失败与否都运行所有测试。若不带此标志，Cargo 会在第一个可执行文件失败后退出。Rust 测试框架会运行可执行文件内的全部测试直至完成；此标志仅作用于整个可执行文件。

包选择

默认情况下，若未给出包选择选项，所选包取决于所选清单文件（若未给出 --manifest-path，则基于当前工作目录）。若清单是工作空间根，则选择该工作空间的默认成员；否则仅选择清单所定义的包。

工作空间的默认成员可通过根清单中的 workspace.default-members 键显式设置。若未设置，虚拟工作空间将包含所有工作空间成员（等价于传入 --workspace），非虚拟工作空间将仅包含根 crate 本身。

-p spec…

--package spec…

Test only the specified packages. SPEC 格式见 cargo-pkgid(1)。 此标志可指定多次，并支持常见的 Unix glob 模式，如 *、? 和 []。不过，为避免 shell 在 Cargo 处理之前意外展开 glob 模式，必须用单引号或双引号括住每个模式。

--workspace

测试工作空间中的所有成员。

--all

--workspace 的已弃用别名。

--exclude SPEC…

排除指定的包。必须与 --workspace 标志一起使用。 此标志可指定多次，并支持常见的 Unix glob 模式，如 *、? 和 []。不过，为避免 shell 在 Cargo 处理之前意外展开 glob 模式，必须用单引号或双引号括住每个模式。

目标选择

若未给出目标选择选项，cargo test 将构建所选包的以下目标：

• lib — 用于与二进制、示例、集成测试和文档测试链接
• bins（仅当构建集成测试且所需特性可用时）
• examples — 以确保它们能编译
• 作为单元测试的 lib
• 作为单元测试的 bins
• 集成测试
• lib 目标的文档测试

可通过在清单设置中为目标设置 test 标志来更改默认行为。将示例设为 test = true 会将该示例作为测试构建并运行，用 libtest 框架替换示例的 main 函数。若不希望替换 main 函数，还需包含 harness = false，此时示例将按原样构建并执行。

将目标设为 test = false 会停止默认对它们进行测试。按名称选取目标的目标选择选项（如 --example foo）会忽略 test 标志，并始终测试给定目标。

可通过在清单中为库设置 doctest = false 来禁用库的文档测试。

参见配置目标 了解更多关于各目标设置的信息。

若选择测试集成测试或基准测试，则会自动构建二进制目标。这样集成测试可以执行该二进制以演练并测试其行为。 在构建并运行集成测试时会设置 CARGO_BIN_EXE_<name> 环境变量， 以便测试可使用 env 宏 或 var 函数 定位可执行文件。

传入目标选择标志将仅测试指定的目标。

注意：--bin、--example、--test 和 --bench 标志也支持常见的 Unix glob 模式，如 *、? 和 []。不过，为避免 shell 在 Cargo 处理之前意外展开 glob 模式，必须用单引号或双引号括住每个 glob 模式。

--lib

测试包的库。

--bin name…

测试指定的二进制目标。 此标志可指定多次，并支持常见的 Unix glob 模式。

--bins

测试所有二进制目标。

--example name…

测试指定的示例。 此标志可指定多次，并支持常见的 Unix glob 模式。

--examples

测试所有示例目标。

--test name…

测试指定的集成测试。 此标志可指定多次，并支持常见的 Unix glob 模式。

--tests

测试所有在清单中设置了 test = true 标志的目标。默认包括作为单元测试构建的库与二进制目标，以及集成测试。请注意这也会构建任何所需依赖，因此 lib 目标可能会被构建两次（一次作为单元测试，一次作为二进制、集成测试等的依赖）。可通过在目标的清单设置中设置 test 标志来启用或禁用目标。

--bench name…

测试指定的基准测试。 此标志可指定多次，并支持常见的 Unix glob 模式。

--benches

测试所有在清单中设置了 bench = true 标志的目标。默认包括作为基准测试构建的库与二进制目标，以及 bench 目标。请注意这也会构建任何所需依赖，因此 lib 目标可能会被构建两次（一次作为基准测试，一次作为二进制、基准测试等的依赖）。可通过在目标的清单设置中设置 bench 标志来启用或禁用目标。

--all-targets

测试所有目标。等价于指定 --lib --bins --tests --benches --examples。

--doc

仅测试库的文档。不能与其他目标选项混用。

特性选择

特性标志用于控制启用哪些特性（feature）。若未给出特性选项，则为每个所选包激活 default 特性。

参见特性文档 了解更多详情。

-F features

--features features

要激活的特性列表，以空格或逗号分隔。工作空间成员的特性可用 package-name/feature-name 语法启用。此标志可指定多次，将启用所有指定的特性。

--all-features

激活所有所选包的全部可用特性。

--no-default-features

不激活所选包的 default 特性。

编译选项

--target triple

Test for the specified target architecture. Flag may be specified multiple times. The default is the host architecture. triple 的一般格式为 <arch><sub>-<vendor>-<sys>-<abi>。

可能的值：

• rustc --print target-list 中任何受支持的目标。
• "host-tuple"，内部会替换为主机目标。若你在交叉编译某些 crate，又不想把主机机器指定为目标（例如可能由多台主机协作的共享项目中的 xtask），这会特别有用。
• 自定义目标规范的路径。更多信息见 自定义目标查找路径。

也可通过 build.target 配置值 指定。

注意：指定此标志会使 Cargo 以不同模式运行，目标产物会放在单独目录中。详情见 构建缓存文档。

-r

--release

使用 release 配置文件测试优化后的产物。 也可使用 --profile 选项按名称选择特定配置文件。

--profile name

使用给定的配置文件测试。 关于配置文件的更多详情见参考文档。

--timings

输出每次编译耗时信息，并跟踪一段时间内的并发信息。

构建结束时会将 cargo-timing.html 文件写入 target/cargo-timings 目录。还会写入一份文件名带时间戳的额外报告，便于查看先前运行。 这些报告仅供人阅读，不提供机器可读的耗时数据。

输出选项

--target-dir directory

所有生成产物与中间文件的目录。也可通过 CARGO_TARGET_DIR 环境变量或 build.target-dir 配置值 指定。 默认为工作空间根目录下的 target。

显示选项

默认情况下，Rust 测试框架会隐藏测试执行的输出以保持结果可读。可通过向测试二进制传递 --no-capture 来恢复测试输出（例如用于调试）：

cargo test -- --no-capture

-v

--verbose

使用详细输出。可指定两次以获得「非常详细」的输出，其中包括依赖警告与构建脚本输出等额外信息。 也可通过 term.verbose 配置值 指定。

-q

--quiet

不打印 cargo 日志消息。 也可通过 term.quiet 配置值 指定。

--color when

控制何时使用彩色输出。有效值：

• auto （默认）： 自动检测终端是否支持颜色。
• always: 始终显示颜色。
• never: 从不显示颜色。

也可通过 term.color 配置值 指定。

--message-format fmt

诊断消息的输出格式。可指定多次，由逗号分隔的值组成。有效值：

• human （默认）： 以人类可读的文本格式显示。与 short 和 json 冲突。
• short: 发出更短的人类可读文本消息。与 human 和 json 冲突。
• json: 向 stdout 发出 JSON 消息。详情见 参考文档。 与 human 和 short 冲突。
• json-diagnostic-short: 确保 JSON 消息的 rendered 字段包含 rustc 的「short」渲染。不能与 human 或 short 一起使用。
• json-diagnostic-rendered-ansi: 确保 JSON 消息的 rendered 字段包含嵌入的 ANSI 颜色代码，以遵循 rustc 的默认配色方案。不能与 human 或 short 一起使用。
• json-render-diagnostics: 指示 Cargo 不要在打印的 JSON 消息中包含 rustc 诊断，而是由 Cargo 自身渲染来自 rustc 的 JSON 诊断。Cargo 自己的 JSON 诊断以及来自 rustc 的其他内容仍会发出。不能与 human 或 short 一起使用。

Manifest 选项

--manifest-path path

Cargo.toml 文件的路径。默认情况下，Cargo 会在当前目录或其任意父目录中搜索 Cargo.toml。

--ignore-rust-version

忽略包中的 rust-version 规范。

--locked

断言使用与生成现有 Cargo.lock 文件时完全相同的依赖与版本。出现以下任一情况时，Cargo 将以错误退出：

• 缺少锁文件。
• 由于依赖解析不同，Cargo 试图更改锁文件。

可用于需要确定性构建的环境，例如 CI 流水线。

--offline

禁止 Cargo 因任何原因访问网络。若未指定此标志，当 Cargo 需要访问网络而网络不可用时会以错误停止。指定此标志后，Cargo 会在可能的情况下尝试在无网络时继续。

注意：这可能导致与在线模式不同的依赖解析结果。Cargo 将仅使用本地已下载的 crate，即使本地索引副本表明可能有更新版本。 可先使用 cargo-fetch(1) 命令下载依赖再离线使用。

也可通过 net.offline 配置值 指定。

--frozen

等价于同时指定 --locked 与 --offline。

通用选项

+toolchain

若 Cargo 通过 rustup 安装，且传给 cargo 的第一个参数以 + 开头，则会被解释为 rustup 工具链名称（例如 +stable 或 +nightly）。 关于工具链覆盖的工作方式，请参阅 rustup 文档。

--config KEY=VALUE or PATH

覆盖 Cargo 配置值。参数应为 TOML 语法的 KEY=VALUE，或指向额外配置文件的路径。此标志可指定多次。 更多信息见 命令行覆盖一节。

-C PATH

在执行任何指定操作之前更改当前工作目录。这会影响诸如 Cargo 默认查找项目清单（Cargo.toml）的位置，以及用于发现 .cargo/config.toml 的目录搜索等。此选项必须出现在命令名之前，例如 cargo -C path/to/my-project build。

此选项仅在 nightly 通道 可用， 并需要 -Z unstable-options 标志才能启用（见 #10098）。

-h

--help

打印帮助信息。

-Z flag

Cargo 的不稳定（仅 nightly）标志。运行 cargo -Z help 查看详情。

杂项选项

--jobs 参数影响测试可执行文件的构建，但不影响运行测试时使用的线程数。Rust 测试框架包含用于控制线程数的选项：

cargo test -j 2 -- --test-threads=2

-j N

--jobs N

并行作业数。也可通过 build.jobs 配置值 指定。默认为 逻辑 CPU 数量。若为负数，则将并行作业上限设为逻辑 CPU 数加上所给值。若 提供字符串 default，则恢复为默认值。 不应为 0。

--future-incompat-report

对本命令执行期间产生的任何未来不兼容警告显示未来不兼容报告

参见 cargo-report(1)

虽然 cargo test 涉及编译，但它不提供 --keep-going 标志。使用 --no-fail-fast 可在不停在第一个失败处的情况下尽可能多地运行测试。若要尽可能多地「编译」测试，可使用 --tests 单独构建测试二进制。例如：

cargo build --tests --keep-going
cargo test --tests --no-fail-fast

环境变量

参见参考文档 了解 Cargo 读取的环境变量详情。

退出状态

• 0: Cargo 成功完成。
• 101: Cargo 未能完成。

示例

1. 执行当前包的所有单元测试与集成测试：

   cargo test
   

2. 仅运行名称匹配过滤字符串的测试：

   cargo test name_filter
   

3. 仅运行特定集成测试中的某个测试：

   cargo test --test int_test_name -- modname::test_name
   

参见

cargo(1)、cargo-bench(1)、测试类型、如何编写测试