cargo-test(1)

名称

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

概要

cargo test [选项] [测试名称] [-- 测试选项]

描述

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

测试过滤参数 TESTNAME 和两个破折号 (--) 之后的所有参数都会传递给测试二进制文件,从而传递给 libtest(rustc 的内置单元测试和微基准测试框架)。如果你要将参数同时传递给 Cargo 和二进制文件,则 -- 之后的参数会传递给二进制文件,之前的参数会传递给 Cargo。有关 libtest 参数的详细信息,请参阅 cargo test -- --help 的输出,并查看 rustc 手册中关于测试如何工作的章节,网址为 https://doc.rust-lang.net.cn/rustc/tests/index.html

例如,这将筛选名称中包含 foo 的测试,并在 3 个线程中并行运行它们

cargo test foo -- --test-threads 3

测试使用 --test 选项编译到 rustc,这会通过将你的代码与 libtest 链接来创建一个特殊的执行文件。该执行文件会自动在多个线程中运行所有使用 #[test] 属性注释的函数。#[bench] 注释的函数也会运行一次迭代,以验证它们是否正常工作。

如果包包含多个测试目标,则每个目标都会如上所述编译为特殊的执行文件,然后依次运行。

可以通过在目标清单设置中设置 harness = false 来禁用 libtest 工具,在这种情况下,你的代码将需要提供自己的 main 函数来处理运行测试。

文档测试

默认情况下也会运行文档测试,它由 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
仅测试指定的包。有关 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 将构建并运行该示例作为测试,并将示例的 main 函数替换为 libtest 工具。如果你不希望替换 main 函数,还要包括 harness = false,在这种情况下,示例将按原样构建和执行。

将目标设置为 test = false 将阻止它们默认情况下被测试。使用名称获取目标的目标选择选项(例如 --example foo)会忽略 test 标志,并且始终会测试给定的目标。

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

有关每个目标的设置的更多信息,请参阅 配置目标

如果选择了集成测试或基准测试进行测试,则会自动构建二进制目标。这允许集成测试执行二进制文件以练习和测试其行为。构建集成测试时会设置 CARGO_BIN_EXE_<name> 环境变量,以便它可以使用 env来查找可执行文件。

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

请注意,--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 清单标志的目标。默认情况下,这包括作为基准测试构建的库和二进制文件,以及基准测试目标。请注意,这也会构建任何所需的依赖项,因此可能会构建两次 lib 目标(一次作为基准测试,一次作为二进制文件、基准测试等的依赖项)。可以通过在目标的清单设置中设置 bench 标志来启用或禁用目标。
--all-targets
测试所有目标。这等效于指定 --lib --bins --tests --benches --examples
--doc
仅测试库的文档。不能与其他目标选项混合使用。

功能选择

功能标志允许你控制启用哪些功能。当没有给出功能选项时,将为每个选定的包激活 default 功能。

有关更多详细信息,请参阅 功能文档

-F features
--features features
要激活的功能的空格或逗号分隔列表。可以使用 包名称/功能名称 语法启用工作区成员的功能。此标志可以多次指定,这会启用所有指定的功能。
--all-features
激活所有选定包的所有可用功能。
--no-default-features
不激活所选包的 default 功能。

编译选项

--target triple
为给定的体系结构进行测试。默认为主机体系结构。triple 的一般格式为 <arch><sub>-<vendor>-<sys>-<abi>。运行 rustc --print target-list 以获取支持的目标列表。此标志可以多次指定。

也可以使用 build.target 配置值来指定此项。

请注意,指定此标志会使 Cargo 在不同的模式下运行,其中目标工件放置在单独的目录中。有关更多详细信息,请参阅 构建缓存 文档。

-r
--release
使用 release 配置文件测试优化的工件。另请参阅 --profile 选项以按名称选择特定的配置文件。
--profile name
使用给定的配置文件进行测试。有关配置文件的更多详细信息,请参阅 参考
--timings=fmts
输出每个编译过程所花费的时间信息,并跟踪随时间变化的并发信息。接受一个可选的、以逗号分隔的输出格式列表;不带参数的--timings将默认为--timings=html。指定输出格式(而不是默认格式)是不稳定的,需要-Zunstable-options。有效的输出格式有:

  • html (不稳定,需要-Zunstable-options):将一个人类可读的文件 cargo-timing.html 写入到 target/cargo-timings 目录,其中包含编译报告。如果您想查看较早的运行结果,也会将带有时间戳的报告写入到同一目录。HTML 输出仅适用于人类阅读,不提供机器可读的定时数据。
  • json (不稳定,需要-Zunstable-options):发出关于定时信息的机器可读 JSON 信息。

输出选项

--target-dir directory
所有生成的文件和中间文件的目录。也可以使用 CARGO_TARGET_DIR 环境变量或 build.target-dir 配置值 来指定。默认为工作区根目录下的 target

显示选项

默认情况下,Rust 测试工具会隐藏测试执行的输出,以保持结果的可读性。可以通过将 --nocapture 传递给测试二进制文件来恢复测试输出(例如,用于调试)。

cargo test -- --nocapture
-v
--verbose
使用详细输出。可以指定两次以获得“非常详细”的输出,其中包括额外的输出,例如依赖项警告和构建脚本输出。也可以使用 term.verbose 配置值 来指定。
-q
--quiet
不打印 cargo 日志消息。也可以使用 term.quiet 配置值 来指定。
--color when
控制何时使用彩色输出。有效的值有:

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

也可以使用 term.color 配置值 来指定。

--message-format fmt
诊断消息的输出格式。可以多次指定,由逗号分隔的值组成。有效的值有:

  • human (默认):以人类可读的文本格式显示。与 shortjson 冲突。
  • short:发出更短的人类可读文本消息。与 humanjson 冲突。
  • json:将 JSON 消息发送到 stdout。有关更多详细信息,请参阅 参考。与 humanshort 冲突。
  • json-diagnostic-short:确保 JSON 消息的 rendered 字段包含 rustc 的“short”渲染。不能与 humanshort 一起使用。
  • json-diagnostic-rendered-ansi:确保 JSON 消息的 rendered 字段包含嵌入的 ANSI 颜色代码,以遵守 rustc 的默认颜色方案。不能与 humanshort 一起使用。
  • json-render-diagnostics:指示 Cargo 不要在打印的 JSON 消息中包含 rustc 的诊断信息,而是 Cargo 本身应该渲染来自 rustc 的 JSON 诊断信息。Cargo 自身的 JSON 诊断和其他来自 rustc 的诊断信息仍然会被发出。不能与 humanshort 一起使用。

清单选项

--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
--lockfile-path PATH
将锁定文件的路径从默认值(<workspace_root>/Cargo.lock)更改为 PATHPATH 必须以 Cargo.lock 结尾(例如,--lockfile-path /tmp/temporary-lockfile/Cargo.lock)。请注意,提供 --lockfile-path 将忽略默认路径下的现有锁定文件,而是使用 PATH 中的锁定文件,或者如果该文件不存在,则将新的锁定文件写入提供的 PATH 中。此标志可用于在只读目录中运行大多数命令,将锁定文件写入提供的 PATH 中。

此选项仅在 nightly channel 上可用,需要 -Z unstable-options 标志才能启用(请参阅 #14421)。

通用选项

+toolchain
如果 Cargo 已通过 rustup 安装,并且 cargo 的第一个参数以 + 开头,则它将被解释为 rustup 工具链名称(例如 +stable+nightly)。有关工具链覆盖如何工作的更多信息,请参阅 rustup 文档
--config KEY=VALUE or PATH
覆盖 Cargo 配置值。参数应采用 KEY=VALUE 的 TOML 语法,或作为额外的配置文件路径提供。此标志可以多次指定。有关更多信息,请参阅 命令行覆盖部分
-C PATH
在执行任何指定操作之前更改当前工作目录。这会影响诸如 cargo 默认查找项目清单 (Cargo.toml) 的位置,以及搜索以发现 .cargo/config.toml 的目录之类的事情。此选项必须出现在命令名称之前,例如 cargo -C path/to/my-project build

此选项仅在 nightly channel 上可用,需要 -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)测试类型如何编写测试