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: automatically wait for subtests to finish #54011

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cjihrig
Copy link
Contributor

@cjihrig cjihrig commented Jul 23, 2024

Some people feel pretty strongly that the test runner should automatically wait for subtests to finish (by the way, that comment seems like something that someone probably should have moderated). The current behavior is for tests to run and cancel any subtests that have not finished in that time. The idea is that people would use await as needed in this case.

This is what the code would look like to make that automatic waiting happen. I would still need to update the docs if we want to land this. From a user perspective the changes are:

  • Nothing ever needs to be awaited anymore. Existing code that does await subtests continues to work. This is a DX improvement.
  • Subtests that timeout just hang instead of being cancelled if you aren't applying a test timeout. This is a worse DX IMO.

I'd like to know how other people feel about such a change.

cc: @nodejs/test_runner @mcollina

This commit updates the test runner to automatically wait for
subtests to finish.
@cjihrig cjihrig added the semver-major PRs that contain breaking changes and should be released in the next major version. label Jul 23, 2024
@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 Jul 23, 2024
@anonrig
Copy link
Member

anonrig commented Jul 23, 2024

How do you feel about this change?

@cjihrig
Copy link
Contributor Author

cjihrig commented Jul 23, 2024

Mostly indifferent. I don't like the bit of extra complexity or shipping breaking changes in general. It's also more magic automatically awaiting async operations (although suites already do this, so it's a bit more consistent), and artificially keeping the event loop alive. I can appreciate making things a little simpler though.

@mcollina
Copy link
Member

I think I'm ok with this change, and I think adding the extra complexity matches user expectations.

I'll be hide that comment.

@MoLow
Copy link
Member

MoLow commented Jul 24, 2024

I am in favor of this change (not because of that comment 😃)

@@ -128,7 +128,7 @@ const tests = [
{ name: 'test-runner/output/name_pattern_with_only.js' },
{ name: 'test-runner/output/skip_pattern.js' },
{ name: 'test-runner/output/unfinished-suite-async-error.js' },
{ name: 'test-runner/output/unresolved_promise.js' },
// { name: 'test-runner/output/unresolved_promise.js' },
Copy link
Member

Choose a reason for hiding this comment

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

maybe this should be removed

@khaosdoctor
Copy link
Member

I'm also in favor of this, mostly because today the behaviour of the subtests (and tests), at least to me, seem a bit different from what I'd expect. As an user I'd like to just write the tests without having to care if they're promises or not because the runner should (in theory) be able to handle all pending promises and automatically close them.

In the meantime, I suggest we add a better error message for those cases, so instead of "Test did not finish before its parent" we could include something like "Did you forget to await a subtest?" or something like this.

@nicholaswmin
Copy link

I don't like the bit of extra complexity or shipping breaking changes in general. It's also more magic automatically awaiting async operations

FTR I agree with this too as strange as it sounds."¯_(ツ)_/¯

@nicholaswmin
Copy link

nicholaswmin commented Aug 17, 2024

Hi guys - Ive made that comment - I don't like this change. I think I was wrong. A misalignment of this nature is probably a bad thing. Sorry for the confusion.

I still do think that the test runner is going to be enormously problematic for people with less experience though. I wouldn't dare ask someone without substantial NodeJS experience to write a serious test suite with it.
It's not the test runner itself that's the problem but rather the surprising misalignment between the semantics
of await-able stuff and the fact the Eloop doesn't actually wait for them.

I stand behind my comment that test runners need to be particularly ergonomic because of their usage context.

But I'm also starting to think that having it align it with the peculiarities of Node is preferable to magic. If there's gonna be a change - i think it should be upstream, to how Promises and the EL interact.

Also that's the way i talk - I don't mean no disrespect to anyone; I can't even if I wanted - I spend more time with the test runner than with actual people so thank you for you work. I'll try to be more considerate in the future with my phrasing.

Sorry for the confusion, only my 2c.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-ci PRs that need a full CI run. semver-major PRs that contain breaking changes and should be released in the next major version. test_runner Issues and PRs related to the test runner subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants