Skip to content
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.

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

Running tests with cargo-nextest #1280

Closed
NobodyXu opened this issue May 10, 2023 · 8 comments
Closed

Running tests with cargo-nextest #1280

NobodyXu opened this issue May 10, 2023 · 8 comments
Assignees

Comments

@NobodyXu
Copy link
Contributor

cargo-nextest can dramatically speedup testing, especially for projects with a lot of tests, though it currently doesn't support running doc-tests in parallel.

Is it possible for cargo-tarpaulin to use cargo-nextest to run tests in parallel and then run cargo test --doc ... for doc-tests?

Or maybe cargo-tarpaulin can reuse infrastructure created by cargo-nextest to speedup itself?

@xd009642
Copy link
Owner

I think this is a duplicate (there should be another one somewhere), I've slightly put off doing this because it would be implemented only for the llvm coverage and not ptrace based coverage (nextest won't work well with ptrace based tracers like kcov or tarpaulins ptrace engine). Just means another set of mutually exclusive configuration that needs to be figured out

@NobodyXu
Copy link
Contributor Author

NobodyXu commented May 10, 2023

not ptrace based coverage (nextest won't work well with ptrace based tracers like kcov or tarpaulins ptrace engine). Just means another set of mutually exclusive configuration that needs to be figured out

Perhaps you can use nextest-runner to implement this in this crate instead of using cargo-nextest?

@xd009642
Copy link
Owner

hmm maybe, I'll have to look into it - wonder how the Noop signal handler affects the usage of the rest of nextest 🤔

@NobodyXu
Copy link
Contributor Author

hmm maybe, I'll have to look into it - wonder how the Noop signal handler affects the usage of the rest of nextest 🤔

Not sure, but AFAIK nextest-runner uses tokio::signal.

So if you also use tokio::signal, it should be ok.

@xd009642
Copy link
Owner

I do not, for it to work with ptrace based traces nextest needs to ignore all signals otherwise tarpaulin can't handle them - tarpaulin's just using ptrace directly

@NobodyXu
Copy link
Contributor Author

@xd009642 nextest-runner does support registering no-op signal handler.

tokio::process would still register a signal handler for SIGCHLD and call waitpid, that's indeed a problem.

Perhaps you can get in contact with upstream and see if they are willing to support this use case?

@RobbieMcKinstry
Copy link

#992 is the issue that this is a duplicate of. 👍🏻 ❤️

@NobodyXu
Copy link
Contributor Author

NobodyXu commented Jul 9, 2023

#992 is the issue that this is a duplicate of. 👍🏻 ❤️

Thanks, I will close this as duplicate

@NobodyXu NobodyXu closed this as not planned Won't fix, can't repro, duplicate, stale Jul 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants