Add a counter to the status line with each test#2618
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2618 +/- ##
==========================================
- Coverage 78.40% 78.39% -0.01%
==========================================
Files 107 107
Lines 24861 24966 +105
==========================================
+ Hits 19492 19572 +80
- Misses 5369 5394 +25 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
80fab3d to
353842f
Compare
|
Thanks. I think the more complex heuristic described in #526 (comment) is required here. I hope it's not too much of a burden. Looking at the output, I'd also put the counter after the time taken. |
f02ad4c to
16736ab
Compare
|
Thanks, hoping to look at this soon (currently dealing with a hard deadline at my workplace) |
| }; | ||
|
|
||
| // Print the time taken and the name of the test. | ||
| write!( |
There was a problem hiding this comment.
A couple of comments here:
- This looks too similar to stress test counters (try out
--stress-count 5or similar). I think we'll somehow need to make it clear that this isn't the stress test counter. Using parentheses might work:
PASS [ 1.860s] [1/10] ( 40/300) integration-tests::integration test_relocated_run
- I think the duration should stay where it is, and that the counter should be displayed after that as well as after the stress test counter.
There was a problem hiding this comment.
Sure thing, updated.
sunshowers
left a comment
There was a problem hiding this comment.
Looks good, thanks! I just released cargo-nextest 0.9.106 as an urgent bugfix, but I'll get this in for 0.9.107 within the next few days.
This adds a counter to each status line, so that one doesn't have to guess how many tests are remaining when the progress bar is not visible (think in CI):
It's been a long requested feature: #526. As a casual observer of test runs with 5000+ tests, this would be nice to have.
As is, it shows the counter unconditionally. In #526 @sunshowers suggested a more complicated heuristic (see #526 (comment)), which I can probably take a stab at next, if it still makes sense.