-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
test_runner: add timeout support to test plan #56765
Conversation
Review requested:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #56765 +/- ##
==========================================
+ Coverage 89.10% 90.34% +1.24%
==========================================
Files 665 629 -36
Lines 193203 184445 -8758
Branches 37220 36038 -1182
==========================================
- Hits 172158 166646 -5512
+ Misses 13771 10918 -2853
+ Partials 7274 6881 -393
|
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 looking better.
Probably worth cc'ing @jsumners here as well.
const { Readable } = require('node:stream'); | ||
|
||
suite('input validation', () => { |
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.
I would actually add all of these new tests to a separate "regular" test file. I don't think we necessarily need to check snapshot output for these. Snapshot tests are more tedious to maintain over time (they need regenerated and introduce merge conflicts). Plus, the linter doesn't run on fixture files.
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.
As soon as possible I'll update these tests
This is looking good to me. I'm disappointed that we can't default a timeout (I believe there will be confusion about why, likely broken, tests never end), but this is still a win. |
d9a7124
to
08951bd
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.
lgtm
* If a number, it specifies the maximum wait time in milliseconds | ||
before timing out while waiting for expected assertions and subtests to be matched. | ||
If the timeout is reached, the test will fail. |
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.
Should the maximal value be pointed out here?
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.
Are you suggesting that there should be a maximum value possible for the wait?
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.
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.
I don't see a need for it. If someone wants to set the timeout to Number.MAX_VALUE
, then that's on them. I think most people will be reasonable and set it on the order of seconds.
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.
IMHO, validating the maximum value is a good way to inform the user of misuse.
I honestly would avoid reporting this maximum in the documentation, as has been done in this case https://github.com/nodejs/node/pull/56595/files .
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.
@atlowChemi @jsumners If you are okay with this, I would avoid documenting this implementation detail!
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.
I am good with the PR as it is.
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.
I'll just address the last comment related to tests and restart the CIs
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.
@pmarchini I left this comment while approving the PR - so this is non-blocking IMHO 🙂
6bed95c
to
33993c8
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
I should have addressed the CI issue (my bad for a @cjihrig @atlowChemi, I'm refactoring the tests to use the This PR is almost stale, and the refactor will also affect tests that are not part of this PR. WDYT? |
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.
lgtm
I agree with this. Get this landed and then refactor. |
Landed in 8c2df73 |
PR-URL: #56765 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
PR-URL: #56765 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
This PR attempts to address #56758.
One major concern about this feature: to allow the timeout to interrupt the tests the
--test-force-exit flag
is required.I'm opening this PR as a draft to validate the implementation and behaviour.
Documentation still needs to be updated!