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

test_runner: add timeout support to test plan #56765

Merged
merged 10 commits into from
Feb 23, 2025

Conversation

pmarchini
Copy link
Member

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!

@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/test_runner

@nodejs-github-bot nodejs-github-bot added needs-ci PRs that need a full CI run. test_runner Issues and PRs related to the test runner subsystem. labels Jan 26, 2025
@pmarchini pmarchini requested a review from cjihrig January 26, 2025 00:45
@pmarchini pmarchini requested a review from cjihrig January 27, 2025 17:47
@pmarchini pmarchini marked this pull request as ready for review January 27, 2025 17:48
Copy link

codecov bot commented Jan 27, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.34%. Comparing base (79f96b6) to head (90e566f).
Report is 73 commits behind head on main.

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     
Files with missing lines Coverage Δ
lib/internal/test_runner/test.js 97.31% <100.00%> (+0.22%) ⬆️

... and 114 files with indirect coverage changes

Copy link
Contributor

@cjihrig cjihrig left a 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', () => {
Copy link
Contributor

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.

Copy link
Member Author

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

@jsumners
Copy link
Contributor

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.

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@cjihrig cjihrig added the request-ci Add this label to start a Jenkins CI on a PR. label Feb 9, 2025
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Feb 9, 2025
@nodejs-github-bot
Copy link
Collaborator

Comment on lines +3403 to +3411
* 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.
Copy link
Member

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?

Copy link
Contributor

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jsumners, yes, at the moment the maximum is const { TIMEOUT_MAX } = require('internal/timers');, here a partial reference #11198

Copy link
Contributor

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.

Copy link
Member Author

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 .

Copy link
Member Author

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!

Copy link
Contributor

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.

Copy link
Member Author

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

Copy link
Member

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 🙂

@atlowChemi atlowChemi added the request-ci Add this label to start a Jenkins CI on a PR. label Feb 16, 2025
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Feb 16, 2025
@nodejs-github-bot

This comment was marked as outdated.

@nodejs-github-bot

This comment was marked as outdated.

@nodejs-github-bot

This comment was marked as outdated.

@nodejs-github-bot
Copy link
Collaborator

@pmarchini
Copy link
Member Author

image There's a related failure in the CI, I'll investigate ASAP

@pmarchini
Copy link
Member Author

I should have addressed the CI issue (my bad for a platformTimeout inside the snapshots).

@cjihrig @atlowChemi, I'm refactoring the tests to use the run function instead of snapshots.
I think it would be better to do this in a separate PR, starting with a first commit that includes both the "old" and "new" tests.

This PR is almost stale, and the refactor will also affect tests that are not part of this PR.

WDYT?

@pmarchini pmarchini added the request-ci Add this label to start a Jenkins CI on a PR. label Feb 23, 2025
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Feb 23, 2025
@nodejs-github-bot
Copy link
Collaborator

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@cjihrig
Copy link
Contributor

cjihrig commented Feb 23, 2025

I think it would be better to do this in a separate PR

I agree with this. Get this landed and then refactor.

@pmarchini pmarchini added commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. author ready PRs that have at least one approval, no pending requests for changes, and a CI started. and removed commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. labels Feb 23, 2025
@atlowChemi atlowChemi added the commit-queue Add this label to land a pull request using GitHub Actions. label Feb 23, 2025
@nodejs-github-bot nodejs-github-bot removed the commit-queue Add this label to land a pull request using GitHub Actions. label Feb 23, 2025
@nodejs-github-bot nodejs-github-bot merged commit 8c2df73 into nodejs:main Feb 23, 2025
69 checks passed
@nodejs-github-bot
Copy link
Collaborator

Landed in 8c2df73

targos pushed a commit that referenced this pull request Feb 25, 2025
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>
targos pushed a commit that referenced this pull request Feb 25, 2025
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. needs-ci PRs that need a full CI run. test_runner Issues and PRs related to the test runner subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants