-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Avoid iterating files when --exact
is passed in
#49
Conversation
@sunshowers I wasn't exactly sure how the testing should be implemented. The only existing test justs run the Is that the sort of thing you had in mind? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome! Thank you, just a couple of minor comments, and some notes below.
The only existing test justs run the harness! macro over a test directory and doesn't really assert anything. I figure that there would need to be some higher level integration test that runs another binary built with the harness! macro (assuming that the system has cargo-nextest installed), and makes assertions about its output.
Haha, good question. Definitely something we'd like to address eventually with the libtest JSON output or similar, but we're not quite there yet. In particular we don't currently have deserializers for the libtest format; nextest-rs/nextest#1152 has tests for it.
But we can definitely do some kinds of testing. Some things to test against would be:
- in the test environment, we have an assertion against hitting the full scan (this can be controlled via an internal-only env var)
- the human-readable output has the right "Summary" line in it. I know it's documented to not be stable -- but it is part of the nextest org, and if it changes we can just fix it.
src/runner.rs
Outdated
.collect(); | ||
|
||
match exact_tests.len() { | ||
0 if is_nextest() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this just have an outer if is_nextest()
condition?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, and that would be fine.
I wrote it like this because it does the cheap part (length comparison) first and the (relatively) expensive part (env var string comparison) second. It's never going to matter performance-wise to just always check the environment variable. I'll do it that way.
src/runner.rs
Outdated
} | ||
|
||
fn is_nextest() -> bool { | ||
std::env::var_os("NEXTEST").is_some_and(|val| val.eq("1")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be val == "1"
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #49 +/- ##
==========================================
+ Coverage 86.33% 88.69% +2.36%
==========================================
Files 4 4
Lines 139 230 +91
==========================================
+ Hits 120 204 +84
- Misses 19 26 +7 ☔ View full report in Codecov by Sentry. |
It seems I used a feature (is_some_and) that was unstable in Rust 1.66 (the MSRV I presume). Maybe this project could be using the new MSRV clippy lint? I think in theory it would lint a case like this when running on a newer version of rust. |
I hadn't heard of this! Sure, happy to take a change for it. |
Ahh looks like it's the new |
(going by https://rust-lang.github.io/rust-clippy/master/index.html#/incompatible_msrv which says 1.78) |
OK maybe an improvement for the future, then. |
Yeah -- given that it's enabled by default in 1.78, hopefully it'll just happen for free though. |
9c4ee86
to
3799e6b
Compare
I think my new integration test is failing in CI because colour is being forced on in the nextest output. I'll see if I can force it back off. |
3799e6b
to
f31a937
Compare
Let me know what you think of the new rudimentary integration test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few more comments, thanks!
This fixes a quadratic performance issue in which the test directories are iterated for every test case when run under nextest.
f31a937
to
32942ad
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic, thanks!
Makes sense
Oops! I should have remembered that
You're welcome |
This fixes a quadratic performance issue in which the test directories are iterated for every test case when run under nextest.
Fixes #8.