1CARGO-TEST(1) General Commands Manual CARGO-TEST(1)
2
6 cargo-test — Execute unit and integration tests of a package
7
9 cargo test [options] [testname] [-- test-options]
10
12 Compile and execute unit, integration, and documentation tests.
13 The test filtering argument TESTNAME and all the arguments following
15 the two dashes (--) are passed to the test binaries and thus to libtest
16 (rustc’s built in unit-test and micro-benchmarking framework). If
17 you’re passing arguments to both Cargo and the binary, the ones after
18 -- go to the binary, the ones before go to Cargo. For details about
19 libtest’s arguments see the output of cargo test -- --help and check
20 out the rustc book’s chapter on how tests work at
21 <https://doc.rust-lang.org/rustc/tests/index.html>.
22 As an example, this will filter for tests with foo in their name and
24 run them on 3 threads in parallel:
25 cargo test foo -- --test-threads 3
27 Tests are built with the --test option to rustc which creates a special
29 executable by linking your code with libtest. The executable
30 automatically runs all functions annotated with the #[test] attribute
31 in multiple threads. #[bench] annotated functions will also be run with
32 one iteration to verify that they are functional.
33 If the package contains multiple test targets, each target compiles to
35 a special executable as aforementioned, and then is run serially.
36 The libtest harness may be disabled by setting harness = false in the
38 target manifest settings, in which case your code will need to provide
39 its own main function to handle running tests.
40 Documentation tests
42 Documentation tests are also run by default, which is handled by
43 rustdoc. It extracts code samples from documentation comments of the
44 library target, and then executes them.
45 Different from normal test targets, each code block compiles to a
47 doctest executable on the fly with rustc. These executables run in
48 parallel in separate processes. The compilation of a code block is in
49 fact a part of test function controlled by libtest, so some options
50 such as --jobs might not take effect. Note that this execution model of
51 doctests is not guaranteed and may change in the future; beware of
52 depending on it.
53 See the rustdoc book <https://doc.rust-lang.org/rustdoc/> for more
55 information on writing doc tests.
56 Working directory of tests
58 The working directory when running each unit and integration test is
59 set to the root directory of the package the test belongs to. Setting
60 the working directory of tests to the package’s root directory makes it
61 possible for tests to reliably access the package’s files using
62 relative paths, regardless from where cargo test was executed from.
63 For documentation tests, the working directory when invoking rustdoc is
65 set to the workspace root directory, and is also the directory rustdoc
66 uses as the compilation directory of each documentation test. The
67 working directory when running each documentation test is set to the
68 root directory of the package the test belongs to, and is controlled
69 via rustdoc’s --test-run-directory option.
70
72 Test Options
73 --no-run
74 Compile, but don’t run tests.
75 --no-fail-fast
77 Run all tests regardless of failure. Without this flag, Cargo will
78 exit after the first executable fails. The Rust test harness will
79 run all tests within the executable to completion, this flag only
80 applies to the executable as a whole.
81 Package Selection
83 By default, when no package selection options are given, the packages
84 selected depend on the selected manifest file (based on the current
85 working directory if --manifest-path is not given). If the manifest is
86 the root of a workspace then the workspaces default members are
87 selected, otherwise only the package defined by the manifest will be
88 selected.
89 The default members of a workspace can be set explicitly with the
91 workspace.default-members key in the root manifest. If this is not set,
92 a virtual workspace will include all workspace members (equivalent to
93 passing --workspace), and a non-virtual workspace will include only the
94 root crate itself.
95 -p spec…, --package spec…
97 Test only the specified packages. See cargo-pkgid(1) for the SPEC
98 format. This flag may be specified multiple times and supports
99 common Unix glob patterns like *, ? and []. However, to avoid your
100 shell accidentally expanding glob patterns before Cargo handles
101 them, you must use single quotes or double quotes around each
102 pattern.
103 --workspace
105 Test all members in the workspace.
106 --all
108 Deprecated alias for --workspace.
109 --exclude SPEC…
111 Exclude the specified packages. Must be used in conjunction with
112 the --workspace flag. This flag may be specified multiple times and
113 supports common Unix glob patterns like *, ? and []. However, to
114 avoid your shell accidentally expanding glob patterns before Cargo
115 handles them, you must use single quotes or double quotes around
116 each pattern.
117 Target Selection
119 When no target selection options are given, cargo test will build the
120 following targets of the selected packages:
121 • lib — used to link with binaries, examples, integration tests, and
123 doc tests
124 • bins (only if integration tests are built and required features are
126 available)
127 • examples — to ensure they compile
129 • lib as a unit test
131 • bins as unit tests
133 • integration tests
135 • doc tests for the lib target
137 The default behavior can be changed by setting the test flag for the
139 target in the manifest settings. Setting examples to test = true will
140 build and run the example as a test, replacing the example’s main
141 function with the libtest harness. If you don’t want the main function
142 replaced, also include harness = false, in which case the example will
143 be built and executed as-is.
144 Setting targets to test = false will stop them from being tested by
146 default. Target selection options that take a target by name (such as
147 --example foo) ignore the test flag and will always test the given
148 target.
149 Doc tests for libraries may be disabled by setting doctest = false for
151 the library in the manifest.
152 See Configuring a target
154 <https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target>
155 for more information on per-target settings.
156 Binary targets are automatically built if there is an integration test
158 or benchmark being selected to test. This allows an integration test to
159 execute the binary to exercise and test its behavior. The
160 CARGO_BIN_EXE_<name> environment variable
161 <https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates>
162 is set when the integration test is built so that it can use the env
163 macro <https://doc.rust-lang.org/std/macro.env.html> to locate the
164 executable.
165 Passing target selection flags will test only the specified targets.
167 Note that --bin, --example, --test and --bench flags also support
169 common Unix glob patterns like *, ? and []. However, to avoid your
170 shell accidentally expanding glob patterns before Cargo handles them,
171 you must use single quotes or double quotes around each glob pattern.
172 --lib
174 Test the package’s library.
175 --bin name…
177 Test the specified binary. This flag may be specified multiple
178 times and supports common Unix glob patterns.
179 --bins
181 Test all binary targets.
182 --example name…
184 Test the specified example. This flag may be specified multiple
185 times and supports common Unix glob patterns.
186 --examples
188 Test all example targets.
189 --test name…
191 Test the specified integration test. This flag may be specified
192 multiple times and supports common Unix glob patterns.
193 --tests
195 Test all targets in test mode that have the test = true manifest
196 flag set. By default this includes the library and binaries built
197 as unittests, and integration tests. Be aware that this will also
198 build any required dependencies, so the lib target may be built
199 twice (once as a unittest, and once as a dependency for binaries,
200 integration tests, etc.). Targets may be enabled or disabled by
201 setting the test flag in the manifest settings for the target.
202 --bench name…
204 Test the specified benchmark. This flag may be specified multiple
205 times and supports common Unix glob patterns.
206 --benches
208 Test all targets in benchmark mode that have the bench = true
209 manifest flag set. By default this includes the library and
210 binaries built as benchmarks, and bench targets. Be aware that this
211 will also build any required dependencies, so the lib target may be
212 built twice (once as a benchmark, and once as a dependency for
213 binaries, benchmarks, etc.). Targets may be enabled or disabled by
214 setting the bench flag in the manifest settings for the target.
215 --all-targets
217 Test all targets. This is equivalent to specifying --lib --bins
218 --tests --benches --examples.
219 --doc
221 Test only the library’s documentation. This cannot be mixed with
222 other target options.
223 Feature Selection
225 The feature flags allow you to control which features are enabled. When
226 no feature options are given, the default feature is activated for
227 every selected package.
228 See the features documentation
230 <https://doc.rust-lang.org/cargo/reference/features.html#command-line-feature-options>
231 for more details.
232 -F features, --features features
234 Space or comma separated list of features to activate. Features of
235 workspace members may be enabled with package-name/feature-name
236 syntax. This flag may be specified multiple times, which enables
237 all specified features.
238 --all-features
240 Activate all available features of all selected packages.
241 --no-default-features
243 Do not activate the default feature of the selected packages.
244 Compilation Options
246 --target triple
247 Test for the given architecture. The default is the host
248 architecture. The general format of the triple is
249 <arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for
250 a list of supported targets. This flag may be specified multiple
251 times.
252 This may also be specified with the build.target config value
254 <https://doc.rust-lang.org/cargo/reference/config.html>.
255 Note that specifying this flag makes Cargo run in a different mode
257 where the target artifacts are placed in a separate directory. See
258 the build cache
259 <https://doc.rust-lang.org/cargo/guide/build-cache.html>
260 documentation for more details.
261 -r, --release
263 Test optimized artifacts with the release profile. See also the
264 --profile option for choosing a specific profile by name.
265 --profile name
267 Test with the given profile. See the the reference
268 <https://doc.rust-lang.org/cargo/reference/profiles.html> for more
269 details on profiles.
270 --ignore-rust-version
272 Test the target even if the selected Rust compiler is older than
273 the required Rust version as configured in the project’s
274 rust-version field.
275 --timings=fmts
277 Output information how long each compilation takes, and track
278 concurrency information over time. Accepts an optional
279 comma-separated list of output formats; --timings without an
280 argument will default to --timings=html. Specifying an output
281 format (rather than the default) is unstable and requires
282 -Zunstable-options. Valid output formats:
283 • html (unstable, requires -Zunstable-options): Write a
285 human-readable file cargo-timing.html to the
286 target/cargo-timings directory with a report of the
287 compilation. Also write a report to the same directory with a
288 timestamp in the filename if you want to look at older runs.
289 HTML output is suitable for human consumption only, and does
290 not provide machine-readable timing data.
291 • json (unstable, requires -Zunstable-options): Emit
293 machine-readable JSON information about timing information.
294 Output Options
296 --target-dir directory
297 Directory for all generated artifacts and intermediate files. May
298 also be specified with the CARGO_TARGET_DIR environment variable,
299 or the build.target-dir config value
300 <https://doc.rust-lang.org/cargo/reference/config.html>. Defaults
301 to target in the root of the workspace.
302 Display Options
304 By default the Rust test harness hides output from test execution to
305 keep results readable. Test output can be recovered (e.g., for
306 debugging) by passing --nocapture to the test binaries:
307 cargo test -- --nocapture
309 -v, --verbose
311 Use verbose output. May be specified twice for “very verbose”
312 output which includes extra output such as dependency warnings and
313 build script output. May also be specified with the term.verbose
314 config value
315 <https://doc.rust-lang.org/cargo/reference/config.html>.
316 -q, --quiet
318 Do not print cargo log messages. May also be specified with the
319 term.quiet config value
320 <https://doc.rust-lang.org/cargo/reference/config.html>.
321 --color when
323 Control when colored output is used. Valid values:
324 • auto (default): Automatically detect if color support is
326 available on the terminal.
327 • always: Always display colors.
329 • never: Never display colors.
331 May also be specified with the term.color config value
333 <https://doc.rust-lang.org/cargo/reference/config.html>.
334 --message-format fmt
336 The output format for diagnostic messages. Can be specified
337 multiple times and consists of comma-separated values. Valid
338 values:
339 • human (default): Display in a human-readable text format.
341 Conflicts with short and json.
342 • short: Emit shorter, human-readable text messages. Conflicts
344 with human and json.
345 • json: Emit JSON messages to stdout. See the reference
347 <https://doc.rust-lang.org/cargo/reference/external-tools.html#json-messages>
348 for more details. Conflicts with human and short.
349 • json-diagnostic-short: Ensure the rendered field of JSON
351 messages contains the “short” rendering from rustc. Cannot be
352 used with human or short.
353 • json-diagnostic-rendered-ansi: Ensure the rendered field of JSON
355 messages contains embedded ANSI color codes for respecting
356 rustc’s default color scheme. Cannot be used with human or
357 short.
358 • json-render-diagnostics: Instruct Cargo to not include rustc
360 diagnostics in JSON messages printed, but instead Cargo itself
361 should render the JSON diagnostics coming from rustc. Cargo’s
362 own JSON diagnostics and others coming from rustc are still
363 emitted. Cannot be used with human or short.
364 Manifest Options
366 --manifest-path path
367 Path to the Cargo.toml file. By default, Cargo searches for the
368 Cargo.toml file in the current directory or any parent directory.
369 --frozen, --locked
371 Either of these flags requires that the Cargo.lock file is
372 up-to-date. If the lock file is missing, or it needs to be updated,
373 Cargo will exit with an error. The --frozen flag also prevents
374 Cargo from attempting to access the network to determine if it is
375 out-of-date.
376 These may be used in environments where you want to assert that the
378 Cargo.lock file is up-to-date (such as a CI build) or want to avoid
379 network access.
380 --offline
382 Prevents Cargo from accessing the network for any reason. Without
383 this flag, Cargo will stop with an error if it needs to access the
384 network and the network is not available. With this flag, Cargo
385 will attempt to proceed without the network if possible.
386 Beware that this may result in different dependency resolution than
388 online mode. Cargo will restrict itself to crates that are
389 downloaded locally, even if there might be a newer version as
390 indicated in the local copy of the index. See the cargo-fetch(1)
391 command to download dependencies before going offline.
392 May also be specified with the net.offline config value
394 <https://doc.rust-lang.org/cargo/reference/config.html>.
395 Common Options
397 +toolchain
398 If Cargo has been installed with rustup, and the first argument to
399 cargo begins with +, it will be interpreted as a rustup toolchain
400 name (such as +stable or +nightly). See the rustup documentation
401 <https://rust-lang.github.io/rustup/overrides.html> for more
402 information about how toolchain overrides work.
403 --config KEY=VALUE or PATH
405 Overrides a Cargo configuration value. The argument should be in
406 TOML syntax of KEY=VALUE, or provided as a path to an extra
407 configuration file. This flag may be specified multiple times. See
408 the command-line overrides section
409 <https://doc.rust-lang.org/cargo/reference/config.html#command-line-overrides>
410 for more information.
411 -C PATH
413 Changes the current working directory before executing any
414 specified operations. This affects things like where cargo looks by
415 default for the project manifest (Cargo.toml), as well as the
416 directories searched for discovering .cargo/config.toml, for
417 example. This option must appear before the command name, for
418 example cargo -C path/to/my-project build.
419 This option is only available on the nightly channel
421 <https://doc.rust-lang.org/book/appendix-07-nightly-rust.html> and
422 requires the -Z unstable-options flag to enable (see #10098
423 <https://github.com/rust-lang/cargo/issues/10098>).
424 -h, --help
426 Prints help information.
427 -Z flag
429 Unstable (nightly-only) flags to Cargo. Run cargo -Z help for
430 details.
431 Miscellaneous Options
433 The --jobs argument affects the building of the test executable but
434 does not affect how many threads are used when running the tests. The
435 Rust test harness includes an option to control the number of threads
436 used:
437 cargo test -j 2 -- --test-threads=2
439 -j N, --jobs N
441 Number of parallel jobs to run. May also be specified with the
442 build.jobs config value
443 <https://doc.rust-lang.org/cargo/reference/config.html>. Defaults
444 to the number of logical CPUs. If negative, it sets the maximum
445 number of parallel jobs to the number of logical CPUs plus provided
446 value. If a string default is provided, it sets the value back to
447 defaults. Should not be 0.
448 --future-incompat-report
450 Displays a future-incompat report for any future-incompatible
451 warnings produced during execution of this command
452 See cargo-report(1)
454 While cargo test involves compilation, it does not provide a
456 --keep-going flag. Use --no-fail-fast to run as many tests as possible
457 without stopping at the first failure. To “compile” as many tests as
458 possible, use --tests to build test binaries separately. For example:
459 cargo build --tests --keep-going
461 cargo test --tests --no-fail-fast
462
464 See the reference
465 <https://doc.rust-lang.org/cargo/reference/environment-variables.html>
466 for details on environment variables that Cargo reads.
467
469 • 0: Cargo succeeded.
470 • 101: Cargo failed to complete.
472
474 1. Execute all the unit and integration tests of the current package:
475 cargo test
477 2. Run only tests whose names match against a filter string:
479 cargo test name_filter
481 3. Run only a specific test within a specific integration test:
483 cargo test --test int_test_name -- modname::test_name
485
487 cargo(1), cargo-bench(1), types of tests
488 <https://doc.rust-lang.org/cargo/reference/cargo-targets.html#tests>,
489 how to write tests <https://doc.rust-lang.org/rustc/tests/index.html>
490 CARGO-TEST(1)