-
-
Notifications
You must be signed in to change notification settings - Fork 61
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
Ignore all #[test]
-related code automatically
#123
Comments
The idea that probably works here is a helper attribute that generates #[cfg(coverage)]
use coverage_helper::test;
#[test]
fn test() {
} generated: #[cfg(coverage)]
use coverage_helper::test;
#[cfg_attr(coverage, no_coverage)]
#[::core::prelude::v1::test]
fn test() {
} UPDATE: this idea is now implemented as https://github.com/taiki-e/coverage-helper. |
@taiki-e I'm not an expert on attribute macros. Would you (or anyone) be kind enough to translate this into code that we could implement? Adding the |
Above my approach is now implemented as https://github.com/taiki-e/coverage-helper. |
171: Add test for coverage-helper r=taiki-e a=taiki-e https://github.com/taiki-e/coverage-helper cc #123 Co-authored-by: Taiki Endo <te316e89@gmail.com>
I appreciate the coverage-helper crate, but since the For those following along, if you want to exclude test-related code from coverage and base your CI builds on stable Rust versions, there's a more drastic approach that does seem to solve the problem. See adobe/xmp-toolkit-rs#66. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
My projects over the past few years have adopted a directory structure that obviously has this in mind. |
Nah, It's already documented 10 months ago.
|
Would it make sense to exclude |
Seems reasonable to me. |
In the recent rustc, it seems the module-level #[cfg(test)]
#[cfg_attr(coverage_nightly, coverage(off))] // <---
mod tests {
// ...
} (Perhaps coverage-helper library should be deprecated for most cases in favor of the module-level |
Oh yes, that was rust-lang/rust#126721. |
And I've updated documentation to recommend the pattern described in #123 (comment):
|
UPDATE3(taiki-e):
#[coverage(off)]
attribute has been stabilized in rust-lang/rust#130766 (will be included in Rust 1.85).UPDATE2(taiki-e):
See #123 (comment)
UPDATE(taiki-e):
https://github.com/taiki-e/cargo-llvm-cov#exclude-function-from-coverage
AFAIK this is not currently possible (though I would love to be proven wrong), so just filing this as a nice-to-have tracking issue.
What I would like is that only library code counts towards coverage. Having all of the
#[test]
and#[cfg(test)]
code (fn and whole utility modules) count towards coverage metrics right now skews those numbers up quite a bit.Right now
cargo-llvm-cov
automatically ignores all theexamples
andtests
code via-ignore-filename-regex
but unit test functions are still counted (and possibly doctests once those are being fixed [tentative fix in #122]).The text was updated successfully, but these errors were encountered: