--recursive to test an entire workspace?

[matthiaskrgr]

Hi, first of all awesome crate! :D
On just a dual core system it seems to be 10-15% faster than default cargo test. :)

While playing around with it, I wondered if it would be useful to have some kind of --recursive flag that does not only run test in the current directory but also on all other crates of the current workspace.

[epage]

Isn't this handed via --workspace?

[sunshowers]

Thanks for the report! I'm glad that even a dual core system is faster.

As @epage says, this is handled by --workspace. nextest just forwards the build command to cargo test --no-run, so the package selection is identical to cargo test.

[matthiaskrgr]

Hmm.
I was playing around in the clippy repo.
When I cd clippy_lints ; cargo test, it runs tests and doctests that are not executed with either cargo test or cargo test --workspace, I guess this means that this crate that happens to be in the same git repo is not part of the workspace..?

The idea was to have --recursive run these tests as well.

It also looks like cargo nextest run skips the doctests?
Edit: ^ seems to be #16

[sunshowers]

Yes, unfortunately doctests aren't yet supported because of limitations in stable Rust. Going to mark this as closed for now as a result. Thanks again for reporting the issue!

[matthiaskrgr]

Well I would like --recursive to do something like:
find all projects (cargo.tomls) that are either in the current workspace or in a subdirectory,
run cargo nextest on all of these (in parallel).

This does not seem to be what --workspace does because it requires that I actually have configured a workspace in my Cargo.toml.
--recursive should just find all the crates on its own imo (if that's possible) :)

[matthiaskrgr]

Ok I see, I shouldn't have used the work "workspace" in the title, I ment like a "hierarchy of crates and subcrates in a directory" and not an official cargo workspace.

[epage]

Is there a reason you aren't using a workspace? That is generally cargo's approach to working on a group of crates ("generally" because in some cases, path dependencies are relied on instead, mostly due to the lack of "workspaces in workspaces' support).

Without it, other means would be needed to opt crates in and out of each run command. It also becomes less clear what to do with -p and --exclude.

[matthiaskrgr]

I think workspaces only make sense if the crates directly depend on each other and live in the same repo?
In case of clippy for example, there are a couple of libraries in the repo but also a bunch of dev tools for blessing tests for example. The tools mostly stand alone (do not depend on any of the other crates) but may still have their own tests.

For convenience it would be great if there was some simple "run all tests" command.

In CI for example we currently cd into each subproject "by hand" and run cargo test or so.
It would also solve the hassle of adding another tool but then forgetting to actually run its tests on ci (since -r would take care of that automatically)

[epage]

The bigger problem for clippy is that I'm assuming its like cargo and can't have a workspace because its pulled into the rust workspace via submodules.