-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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: count nested tests #47094
Conversation
Review requested:
|
7955d04
to
d493a9b
Compare
ping @nodejs/test_runner can someone review this please? |
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 think this is a change we should make. I left a couple high level comments that I think could make the implementation a bit cleaner.
lib/internal/test_runner/test.js
Outdated
@@ -71,6 +71,8 @@ const kUnwrapErrors = new SafeSet() | |||
.add('uncaughtException').add('unhandledRejection'); | |||
const { testNamePatterns, testOnlyFlag } = parseCommandLine(); | |||
|
|||
const completedTests = new SafeSet(); |
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 like to get rid of this if possible. Each Test
object now has a harness
field that can be used to hold this "process level state." It is only used on the root test, and is currently initialized in harness.js but there is no reason it couldn't be initialized in the Test
constructor. I have considered giving every Test
a reference to the root test for a while now - I think that could simplify some things, including this.
We could put the counters
object in the harness
since it has the same scope as the other pieces of data that are stored in it. Then, instead of tracking all of the tests in a Set
, every test could update the counters directly via this.root.harness.counters
.
I think this would also get rid of the need for omitFromCounters
because each test/suite would be doing its own updating (or not updating) of the counters.
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 like that suggestion very much
@@ -746,6 +769,8 @@ class TestHook extends Test { | |||
} | |||
|
|||
class Suite extends Test { | |||
omitFromCounters = true; | |||
reportedType = 'suite'; |
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.
Maybe we should have a type
field on Test
and everything that extends from it. We could differentiate between tests, suites, hooks, etc.
We could also use Symbol.toStringTag
instead of a normal property or instanceof
(although that one is probably a bigger perf hit).
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.
isnt this what I did? not sure what else are you suggesting?
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 was suggesting adding it to Test
and all of the classes that extend Test
. Right now it's only on Suite
.
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 do not currently see any usage for that, but even if we want that just for the sake of simplifying code it should probably happen in separate PR
lib/internal/test_runner/test.js
Outdated
cancelled: 0, | ||
skipped: 0, | ||
todo: 0, | ||
topLevel: 0, |
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 think it's worth keeping a count of the suites as well.
d493a9b
to
831ab97
Compare
831ab97
to
d98c46e
Compare
Landed in d1eaded |
In [version 20.0.0 (and backported to 19.9.0 and 18.7.0)](nodejs/node#47094) the test runner started reporting on whether a test was a suite. This was exposed to reporters in the `details` object of a `test:pass` or `test:fail` event but this hasn't been documented. This adds the `type` property to both event's `details` object.
In [version 20.0.0 (and backported to 19.9.0 and 18.7.0)](nodejs/node#47094) the test runner started reporting on whether a test was a suite. This was exposed to reporters in the `details` object of a `test:pass` or `test:fail` event but this hasn't been documented. This adds the `type` property to both event's `details` object.
In [version 20.0.0 (and backported to 19.9.0 and 18.7.0)](nodejs/node#47094) the test runner started reporting on whether a test was a suite. This was exposed to reporters in the `details` object of a `test:pass` or `test:fail` event but this hasn't been documented. This adds the `type` property to both event's `details` object.
…philnash In [version 20.0.0 (and backported to 19.9.0 and 18.7.0)](nodejs/node#47094) the test runner started reporting on whether a test was a suite. This was exposed to reporters in the `details` object of a `test:pass` or `test:fail` event but this hasn't been documented. This adds the `type` property to both event's `details` object.
Fixes: #46762
this also introduces a property on the TAP yaml output to allow distinction between a suite and a regular test