Skip to content

Enable specifying --test-threads in Cargo.toml #8430

New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom
Open
matobet opened this issue Jun 29, 2020 · 5 comments
Open

Enable specifying --test-threads in Cargo.toml #8430

matobet opened this issue Jun 29, 2020 · 5 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-test E-hard Experience: Hard S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@matobet
Copy link

matobet commented Jun 29, 2020

I have an integration test suite that does some expensive setup/teardowns and really doesn't support parallel running of individual tests. I always have to run my tests as cargo test -- --test-threads=1 and it would be great if I could specify this somehow in Cargo.toml as this is something inherent to the project and static.

It would be great if this was configurable similarly to the jobs parameter in the [build] section. Perhaps there can be a new section [test] added?

Also if this can be solved somehow with current mechanisms, please advise since anything that obviates me from wrapping the build in a Makefile (that passes the necessary --test-threads param to cargo test) and just using cargo for everything would be a huge boon for me 👍
@matobet matobet added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Jun 29, 2020
@ehuss
Copy link
Contributor

ehuss commented Jul 4, 2020

I think using the RUST_TEST_THREADS environment variable is the only other option right now.

@choubacha
Copy link

I'd like to see this feature added. The [test] table wouldn't work because I think it would conflict with the [[test]] target options. What might be a good other name for it? [testbuild] or [build_test] could work. Perhaps even an optional sub-table [build.test]?

@sveitser sveitser mentioned this issue Jan 24, 2022
Closed
@holi-java
Copy link

I found .cargo/config.toml can specify environment permanently.

[env]
RUST_TEST_THREADS = "1"

melvyn2 added a commit to melvyn2/wireframe-swraster that referenced this issue Jul 7, 2022
@melvyn2
Fix tests being run in parallel, failing SDL init
fb002f5 
The cargo benchmarks also double as tests and so cause the `cargo test` command to fail, as they were not meant to be run in the test harness: the benchmark harness runs each test in sequence as to avoid resource contention, but tests are run in parallel by default.

Multiple SDL contexts can't coexist, so while sequential tests drop the context in time for the next test, parallel tests conflict with eachother for the global context slot and panic/fail.

This is not the best fix but is held up on rust-lang/cargo#8430
@weihanglo
Copy link
Member

weihanglo commented May 15, 2023 •
edited
Loading

I found .cargo/config.toml can specify environment permanently.

[env]
RUST_TEST_THREADS = "1"

It seems to be a proper place for setting RUST_TEST_THREADS, as build.job is also there in Cargo configuration (.cargo/config.toml). I don't think such a flag should be in Cargo.toml.

--test-threads is a flag provided by libtest from rust-lang/rust. The CLI protocol between cargo and other test harnesses is still unclear. #1983 (comment) and #8903 (comment) outline the problem of forwarding flags to test harnesses.

I'd say this issue is effectively resolved by #8430 (comment). Keep it open for the awareness of the test harness protocol of threading control. Labelled as E-hard for the possible effort of design works involved.

@weihanglo weihanglo added S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. E-hard Experience: Hard labels May 15, 2023
@epage
Copy link
Contributor

epage commented May 15, 2023

FYI I'm working on revamping custom test harnesses which we plan to make first class. My current plan for my PoC custom harness is to have a #[test(exclusive)] attribute for tests that need serializing.

For some cases, a workaround is to use cargo nextest which runs all tests in an isolated process.

@empwilli empwilli mentioned this issue Aug 3, 2023
Merged
@djeedai djeedai mentioned this issue Nov 5, 2023
Open
@devinjdangelo devinjdangelo mentioned this issue Feb 29, 2024
Closed
gentoo-bot pushed a commit to gentoo/gentoo that referenced this issue Jan 28, 2025
@thesamesam
cargo.eclass: respect MAKEOPTS for cargo test
ddb45b4 
Without this, while (test) compile jobs respect MAKEOPTS via our config settings
already deployed via the eclass, *test* jobs do not.

We may want to consider setting NEXTEST_TEST_THREADS and/or having
a cargo_enable_tests helper in the eclass at some point too.

Bug: rust-lang/cargo#8430
Signed-off-by: Sam James <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-test E-hard Experience: Hard S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
testing-devex backlog
Status: No status
Milestone
No milestone
Development

No branches or pull requests
6 participants
@ehuss @epage @matobet @choubacha @weihanglo @holi-java