19 releases (breaking)

Uses new Rust 2021

new 0.14.0 Jun 26, 2022
0.12.0 Jun 17, 2022
0.5.0 Mar 22, 2022

#186 in Cargo plugins

Download history 2563/week @ 2022-03-09 6207/week @ 2022-03-16 6372/week @ 2022-03-23 6001/week @ 2022-03-30 6051/week @ 2022-04-06 5939/week @ 2022-04-13 8593/week @ 2022-04-20 10031/week @ 2022-04-27 12266/week @ 2022-05-04 13580/week @ 2022-05-11 9444/week @ 2022-05-18 5816/week @ 2022-05-25 7981/week @ 2022-06-01 6024/week @ 2022-06-08 11541/week @ 2022-06-15 5859/week @ 2022-06-22

32,634 downloads per month
Used in cargo-nextest




nextest-runner on crates.io Documentation (latest release) Documentation (main) Changelog License License

Core functionality for cargo nextest. For a higher-level overview, see that documentation.

Here's the basic flow of operations in nextest.

Building the test list

  1. cargo test --no-run is invoked to build test binaries. (This is handled by cargo-nextest; nextest just processes the messages produced by the command.)
  2. The messages generated by Cargo are processed into a list of list::RustTestArtifact instances.
  3. Separately, a test_filter::TestFilter is created based on text filters, along with the run-ignored and partitioning filters if provided.
  4. The list of test binaries and test filter are combined. Each binary is run with --list to grab the list of tests, the given filters are applied to it, and everything is put together to create a list::TestList.

If cargo nextest list-tests is called, this list::TestList is printed out. If cargo nextest run is called, nextest proceeds to run the tests.

Running the tests

  1. A new runner::TestRunner is created with the test list and appropriate configuration.
  2. The runner sets up two thread pools:
    • The run pool: each thread in this pool executes a test (+ 1 thread for overall management).
    • The wait pool: each thread in this pool monitors the status of a test being run by the run pool.
  3. The test runner is executed with a callback to send reporter::TestEvent instances to the test reporter.
  4. The test runner iterates over the test list to get individual list::TestInstance information. Test instances are sent to the thread pool to be executed.
  5. If a test fails and fail-fast is true, or if a signal is encountered, the run is cancelled; currently executing tests are allowed to complete, but no new tests are scheduled.
  6. The test reporter sees events and prints them to stderr (and aggregates them if necessary based on configs).


See the CONTRIBUTING file for how to help out.


This project is available under the terms of either the Apache 2.0 license or the MIT license.


~1.5M SLoC