Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Cargo runs unit tests when they are disabled and --lib is passed #13668

Open
RalfJung opened this issue Mar 29, 2024 · 6 comments
Open

Cargo runs unit tests when they are disabled and --lib is passed #13668

RalfJung opened this issue Mar 29, 2024 · 6 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-test S-blocked-external Status: ❌ blocked on something out of the direct control of the Cargo project, e.g., upstream fix

Comments

@RalfJung
Copy link
Member

Problem

When a crate has no unit tests (via test = false in its manifest), I would expect cargo to never ever try to run unit tests for that crate.

And yet it turns out that cargo test --lib will run the unit tests.

Steps

  1. Run cargo test --lib --bins --examples --tests --benches (in an attempt to run "everything except for doc tests"), or just cargo test --lib
  2. Note how even if the library has unit tests are disabled, cargo will run them
     Running unittests src/lib.rs (build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/core-04ceb2ced8c36de5)

running 0 tests


test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 7.54µs

Possible Solution(s)

--lib should just be a filter, removing from the usual test set everything that's not a "library unit test". It should not add things that were not present to begin with.

Notes

This is related to but different from #10936

Version

No response

@RalfJung RalfJung added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Mar 29, 2024
@RalfJung
Copy link
Member Author

RalfJung commented Mar 29, 2024

Something similar seems to happen with benchmarks. With a manifest like this

[[bench]]
name = "allocbenches"
path = "benches/lib.rs"
test = true

[[bench]]
name = "vec_deque_append_bench"
path = "benches/vec_deque_append.rs"
harness = false

Running cargo test will only run the first benchmark, but running cargo test --lib --bins --examples --tests --benches will run both -- even though it's not a test and shouldn't be run as a test.

@weihanglo
Copy link
Member

This seems to be covered by rust-lang/testing-devex-team#1> Once we have a new JSON output format, Cargo could get more controls over tests than relying on libtest.

@weihanglo weihanglo added Command-test S-blocked-external Status: ❌ blocked on something out of the direct control of the Cargo project, e.g., upstream fix and removed C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Mar 29, 2024
@weihanglo weihanglo added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Mar 29, 2024
@RalfJung
Copy link
Member Author

I don't think this issue has anything to do with handling the output from the tests. It's all about which tests cargo decides to run.

@weihanglo
Copy link
Member

I see. Sorry I understood it wrong.

--lib is a flag for user to explicitly requests tests in library target to be run, so that is expected. So does other flags like --test, --bench, etc.

test = false controls only the default set of tests being run. See the target selection section.

Setting targets to test = false will stop them from being tested by default. Target selection options that take a target by name (such as --example foo) ignore the test flag and will always test the given target.

@weihanglo
Copy link
Member

--lib should just be a filter, removing from the usual test set everything that's not a "library unit test". It should not add things that were not present to begin with.

The proposed solution can only be solved with rust-lang/testing-devex-team#1, from my understanding, because Cargo needs to run libtest to know if there is any unit test defined.

@RalfJung
Copy link
Member Author

test = false controls only the default set of tests being run. See the target selection section.

That's very surprising... but it explains a lot, thanks.

bors added a commit to rust-lang/miri that referenced this issue Mar 30, 2024
make some doc comments not doc tests

`./miri test --doc` will run doctests even if we have them disabled (that's a cargo quirk: rust-lang/cargo#13668). This fixes that command to not fail.
RalfJung pushed a commit to RalfJung/rust that referenced this issue Mar 31, 2024
make some doc comments not doc tests

`./miri test --doc` will run doctests even if we have them disabled (that's a cargo quirk: rust-lang/cargo#13668). This fixes that command to not fail.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-test S-blocked-external Status: ❌ blocked on something out of the direct control of the Cargo project, e.g., upstream fix
Projects
Status: No status
Development

No branches or pull requests

2 participants